Re: [Nano-devel] aggressive C color highlighting

[David Lawrence Ramsey]

Alexey Toptygin wrote:

<snip>

>>>> color brightblue "//.*"
>>>> color brightblue start="(/){1}\*" end="\*(/){1}"
>
> That's exactly the same as:
>
> color brightblue "//.*"
> color brightblue start="/\*" end="\*/"

Odd.  It didn't seem to do this when I was testing it yesterday, for
some reason, but now it indeed works the same way as the old regex. 
Reverted then, until (or if) I can figure out a better way.  Thanks for
the report.

> The best thing to do, IMO, is to eliminate regions matched by earlier
> rules from being tested by later rules. In this case, the simplest:
>
> color brightblue "//.*"
> color brightblue start="/\*" end="\*/"
>
> will do exactly what we want. In your example, it would match the
> first line with the first rule and not test the second rule against
> it; the second line would not match, and comment on line 3 would be
> handled correctly.
>
> By letting earlier rules call 'dibs' on regions they've already
> matched, we would emulate what the C lexer is doing: if a // comment
> starts, the rest of the line is not processed in any way; if a /*
> comment starts, no other processing will be done until the first */.
> This lets us define complex syntaxes, and handle pathological cases
> correctly: the same way that a C (or other) compiler would. In theory,
> this could also save nano some effort, since no more tests will need
> to be done once the first one matches and the regexes can be simpler.

Interesting idea.  However, there are some cases where overlaps are
needed.  How should a regex that allows overlaps be indicated?  Also,
there's still a problem with the feature freeze, as there doesn't appear
to be any way to implement this without a massive rewrite of the color
code in edit_draw().  I've made some attempts, and I've only succeeded
in royally screwing up the color display.  (I could be wrong, though; if
you or anyone else has any idea how to do this without a massive
rewrite, please speak up.)