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: Brand Huntsman
Subject: Re: [Nano-devel] [PATCH] Per syntax key bindings
Date: Wed, 23 May 2018 15:34:43 -0600

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.

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.



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




reply via email to

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