[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: Brand Huntsman
Subject: Re: [Nano-devel] [PATCH] interpolate functions in string binds
Date: Thu, 30 Aug 2018 18:53:42 -0600

On Thu, 30 Aug 2018 12:44:12 -0300
Marco Diego Aurélio Mesquita <address@hidden> wrote:

> I didn't add such checks.

Ignoring typo functions and not checking if menu supports the function can lead 
to broken binds that do the wrong thing and are hard to check. A bind that 
finishes off by writing the file and exiting is even worse if there was a 
problem and the bind didn't abort. Imagine you write a bind, and in the next 
version a function you used has been renamed or removed (happens all the time). 
Your bind is now broken and does the wrong thing instead of notifying you.

> > 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}"

Could you test all of these with your patch, none of them work (and yes, I 
wrapped each function with ${}). It also seems like your patch only supports 
one function per bind.

"${replace}    ${enter}${verbatim}    ${enter}" opens search prompt and inserts 
"    {verbatim}${enter}". The first ${enter} was removed along with the $ 
before verbatim, but the prompt didn't change to the replacement prompt.

> > 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}]"
> 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:

Would be better to have popcutbuffer and pushcutbuffer functions in nano versus 
push/pop functions that support an argument which means you can't have multiple 
functions per ${}. But I'm not sure what the cutbuffer has to do with undo. I 
want to have the ${enter} and ${cut} consolidated into a single undo point, 
instead of two, but only if requested, not for all string binds. And 
${pushcutbuffer}${cut}${popcutbuffer} looks like whatever you cut is now gone 

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

I was hoping you would post your patch and had a simpler solution. Returning 
the shortcut like you do is much better. But implanting the entire string into 
key buffer and processing it live is not. Parsing fragments in rcfile, and 
having your process_command function inject keycode fragments or return 
function from shortcut fragments would be better. Then errors can be caught in 
rcfile and process_command can abort if a function isn't valid for current 
menu. Best of both worlds. :)

It might be a few days before I can get around to working on it again. But if 
you want, and have time, you can rip the fragment code out of mine and put in 

reply via email to

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