Re: [Nano-devel] 2.3.2pre3

[Mike Frysinger]

On Tuesday 22 January 2013 03:22:20 Chris Allegretta wrote:
> Unfortunately that was by design - is this really prevalent in all of
> our configs that we should repeatedly highlight the same text in
> different colors?

(1)
the issue is generally that highlighting a bit of code depends on the 
surrounding context, but you don't want to highlight that surrounding context.  
so you end up with a general regex earlier on which later regexes refine.

to the shell example, we want to highlight general chars like { and } because 
they get used in function definitions:
        foo() {
                # blah blah
        }
we do that with the line:
        color green "(\{|\}|\(|\)|\;|\]|\[|`|\\|\$|<|>|!|=|&|\|)"

braces also get used with variables, but we want the variables to get 
highlighted differently:
        ${var}
we do that with the line:
        icolor brightred "address@hidden"

with <=nano-2.3.1, we end up coloring all the single chars first, then doing a 
larger regex to look for variables.  with >nano-2.3.1, this can be fixed by 
reversing the order.

(2)
there's also the context problem.  looking at C code, say we want to highlight 
function calls:
        foo();
        printf("bar");
        cow (1, 2, 3);
a simple regex would do:
        color brightwhite "[[:alpha:]_][[:alnum:]_]*[[:space:]]*[(]"
but that ends up highlighting the first "(" too and that's undesirable (and to 
a lesser degree, the whitespace after the function identifier).  the only 
option is to later "undo" that by matching all "(".

for this, we could extend the syntax with an additional "colorize" argument.  
so in the above, we could do:
  color brightwhite "([[:alpha:]_][[:alnum:]_]*)[[:space:]]*[(]" colorize="\1"

since \1 is just the function name, we'd colorize that and leave the 
spacing/paren alone.

> Let me just say the obvious here: this is really really hard to get
> right.  The win of that commit was to solve this awfulness (using an
> example int the same language):
> 
> # Check out this "pretty" comment

well, that line alone indicates an ordering issue.  the overlap is problematic 
when the opposite case is also considered:
        var="some # line"
        # some "line"

there's also the small matter of performance.  the more overlapping we have to 
do, the slower nano gets (i've certainly had to toggle highlighting before 
when editing large files because inserting new text and flipping buffers was 
god 
awful slow).

> I'd intended to implement an "overlap" option (even the commit says
> so) to allow overrlapping higlights of later rules where simple
> swapping of rule ordering wouldn't fix the core issue.  I guess we'll
> have to decide where to go on how many highlights have broken with
> this commit.  Thoughts?

if it's an improvement, we can adjust the syntax files.  the documentation def 
needs updating as it's split between the sample nanorc and the nanorc(5) man 
page.  i'd say create a new colorization section in the nanorc(5) man page and 
move the majority of content out of the sample nanorc file.

i'm not entirely sure what the new behavior is exactly to say whether it's an 
improvement :)
-mike

signature.asc
Description: This is a digitally signed message part.