[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] [PATCH] interpolate functions in string binds

From: Marco Diego Aurélio Mesquita
Subject: Re: [Nano-devel] [PATCH] interpolate functions in string binds
Date: Thu, 30 Aug 2018 12:44:12 -0300
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, Aug 30, 2018 at 05:15:05AM -0600, Brand Huntsman wrote:
> I don't know if Marco is still working on this or if he ran into problems, so 
> I took a shot at it.

I was just a bit sad because I had another rejected feature and decided to take 
few days away from nano. But I'm fine now.

> The first patch simply moves shortcut handling for edit, prompt, help and 
> browser to separate functions that can be called in second patch.
> $$ is used to escape '$' characters that should be raw text.
> One or more space-delimited functions are put inside ${}. This looks so much 
> better than wrapping every function in ${}.
>   ${up} calls do_up
>   ${up down} calls do_up and then do_down
> A ! before a function name tells the function that shift key is pressed.
>   ${!left !left} selects previous two characters

My implementation does not considers multiple commands inside the same ${}, but 
think it would be easy to implement. Also, it does not considers ! like yours, 
but I also think it would be easy to implement.

> The string bind will print an error and won't be created if it can't be 
> parsed. This avoids creating broken binds that do the wrong thing.
> All shortcuts are now checked when used to prevent using functions in menus 
> that don't support them. The search prompt does not support ${up}, you must 
> use ${prevhistory}. If you use an invalid function, it will beep and stop 
> processing the string bind. This avoids continued processing of a now broken 
> bind which might do the wrong thing. If this happens in a prompt, the prompt 
> is left open so you can debug where it went wrong.

I didn't add such checks.

> String binds can call other string binds, sort of. A fragment is a string of 
> keycodes or a single function. "a${up up}b" is 4 fragments. The called bind 
> can be chained to the end of any bind and single fragment binds can be 
> inserted anywhere into any bind.
>   bind ^A "x"
>   bind ^B "x${enter}"
>   bind ^C "^A"
>   bind ^D "^B"
>   bind ^E "^A${enter}"
>   bind ^F "^B${enter}"
> C and D can call any string bind because the call is at the end. E can call A 
> because A only contains a single fragment. F will fail because B has two 
> fragments and F has an additional fragment.

Not sure, but I think my implementation allows arbitrarily recursive binds.

> Example string binds:
> repeat previous search and replace
>   "${replace prevhistory enter prevhistory enter}"
> replace 4-spaces with 1-tab
>   "${replace}    ${enter verbatim}    ${enter}"
>   - the second set of 4 spaces is a tab
> open prompt to execute external command
>   "${insert flipexecute}"
> cut to start of line
>   "${enter left cut}"
> cut to end of line
>   "${enter cut left}"

My example is in the commit message.

> add_to_sclist(get_history_older_void) has more menus than
> add_to_funcs(get_history_older_void), which is missing MFINDINHELP and 
> MEXTCMD. There are other functions missing from some menus. The patch uses 
> the list created by add_to_funcs to check if function is in a menu. This 
> causes up/down arrows in help-search and external-cmd prompts to beep, but 
> they still work. But any string bind using ${prevhistory} in these menus will 
> abort. Is this an oversight or is there a reason these functions aren't in 
> those menus?
> The help menu hides the unbound error message for modifier-less keys such as 
> 'a'. Is there a reason for this? When I press a key and it does nothing, 
> should I assume it is unbound or just doesn't work in the current context? 
> Anyway, string binds that use unbound modifier-less keys in help menu won't 
> notify the user why it failed. The third patch fixes this, unless of course 
> there is a reason not to.

I didn't test my implementation enough to catch bugs.

> ${tab} does not work in prompts, you must use ${verbatim} following by a tab 
> character. This can still cause problems copy/pasting binds, but it would be 
> pretty easy to add something like $\t or $t to interpolate control characters.
> I don't know how the undo code works, but would it be easily possible to 
> force several actions to occupy a single undo? $[...] could be used to wrap a 
> bunch of stuff in a single undo.
>  "$[${enter cut left}]"
> I don't know how useful it would be, but a number inside ${} could repeat the 
> function after it. ${4 !right} or maybe ${!right 4} selects next 4 characters.

What I think we need is a set of stacks. So, we could do something like:

${push cutbuffer}${cut}${pop cutbuffer}

And the cutbuffer would be restored after popping it. We could also add set and 
unset and do similar things:

${push multibuffer}${unset multibuffer}${insert}${flip_execute}ls${enter}${pop 

I'll attach my current implementation. It is much simpler than yours. Please 
check which approach is better.


Attachment: 0001-new-feature-function-interpolation.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]