nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] [PATCH] Per syntax key bindings


From: Marco Diego Aurélio Mesquita
Subject: Re: [Nano-devel] [PATCH] Per syntax key bindings
Date: Wed, 23 May 2018 21:38:17 -0300

On Wed, May 23, 2018 at 6:34 PM, Brand Huntsman <address@hidden> wrote:
> On Wed, 23 May 2018 15:37:43 -0300
> Marco Diego Aurélio Mesquita <address@hidden> wrote:
>
>> The attached patch allows nano to have per-syntax defined key
>> bindings.
>>
>> To avoid problems with the "default" syntax, defining shortcuts
>> already present on the default syntax is not allowed.
>
> The previous fix didn't unbind exit but still tried to bind everything in 
> nanorc. This fix didn't bind everything in nanorc but did unbind exit.
>

With the patch applied I added the following lines
  unbind ^X main
  unbind F2 main
to the end of my .nanorc effectively unbinding exit. When I try to run
nano, it complains that exit was not bound and refuses to run: same as
with master. Am I missing something here?

> I don't know how extendsyntax works (nor do I use it) but if it opens a 
> syntax in nanorc you might want to disallow bind/unbind in it as well. But is 
> it possible to define non-default syntaxes in nanorc? That would complicate 
> everything. You might want to pass a "is_included_file" bool to 
> parse_rcfile() in parse_one_include(). Then only call the syntax bind/unbind 
> if the bool is set.
>

I'm currently using extendsyntax to test this feature. I add
  extendsyntax c bind M-" "Test" all
  extendsyntax c bind ^G "Test2" all
to the end of my .nanorc file then I get binding's that are defined
only for that syntax.

>
> The entire handling of syntaxes is broken because an include file can only 
> use color commands but a syntax defined in nanorc can have non-color commands 
> mixed between color commands. An "endsyntax" command should be required 
> around the syntax body if not in an include file. And fail if endsyntax is 
> used in an include.
>
> syntax ...
>   comment ...
>   color ...
> endsyntax
>
> Then live_syntax would be unset when leaving an include file or syntax block 
> via endsyntax command. The open_syntax parameter in parse_rcfile() could be 
> removed and check live_syntax != NULL instead. The is_included_file would 
> replace the open_syntax parameter. Bind and unbind commands could be moved 
> into the color command section and use sclist or live_syntax->sclist based on 
> live_syntax being null or not.
>
> An error should be thrown if end of nanorc is reached and live_syntax!=NULL, 
> no endsyntax was used.
>
> rcfile_error(N_("Command \"%s\" not allowed in included file")
>
> That error could change based on the is_included_file parameter. If not an 
> included file it would explain that a syntax was not properly closed with 
> endsyntax. This should help users update their broken nanorc files.
>
> And the syntax command should also fail if 
> !is_included_file&&live_syntax!=NULL. An include file could contain two 
> syntaxes without using endsyntax (since endsyntax wouldn't be allowed in 
> include files), but nanorc should require each syntax to be closed with 
> endsyntax. Consistent policies are easier to understand...
>
>

I don't want to fix all that. At least not now. For now, I just want
to get enough done to have the feature working as expected. Of course,
if it breaks something, I want to fix it; if not, I don't care. Can
you send-me some samples of .nanorc which work with current master but
not with the patch applied?



reply via email to

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