Re: [Nano-devel] aggressive C color highlighting

[Alexey Toptygin]

On Wed, 2 Aug 2006, David Lawrence Ramsey wrote:

> > > How about this?
> > >
> > > color brightblue "//.*"
> > > color brightblue start="(/){1}\*" end="\*(/){1}"

That's exactly the same as:

color brightblue "//.*"
color brightblue start="/\*" end="\*/"

> > seems to work :)
>
> Oh good.  I've applied it then.  Note that it's not perfect.  I've just
> found out that if you create a C file with the following lines, they'll
> all be highlighted when some of them shouldn't (it should be obvious
> which):
>
> //* This should be highlighted.
>
> This should not be highlighted.
>
> /*
> This should be highlighted.
> */

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.

                        Alexey