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

[Marco Diego Aurélio Mesquita]

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 
a 
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 
I 
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.

> BUGS:
> 
> 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.

> FUTURE FEATURES:
> 
> ${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 
multibuffer}

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

Thanks!

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