Re: [Nano-devel] disable a time-consuming multiline regex?

[Benno Schulenberg]

On Mon, Jan 18, 2016, at 19:38, address@hidden wrote:
> I was only interested in making everything similar. Here is a snippet
> from nanorc.nanorc
> icolor cyan "^[[:space:]]*##.*$"
> This told me that using ## was considered appropriate by the nano folks
> for their files,

Try running 'src/nano doc/syntax/*rc', and press ^X till it's done.
You will see that ## is used only for the introductory comment.
This is historical, we keep it that way.  All other comments start
with a single #.  (Except in gentoo.nanorc.  You're welcome to
fix that.)

> > > -color brightyellow "<[^=         ]*>" ""(\\.|[^"])*""
> > > +color brightwhite ""[^"\\]*""  
> > 
> > Why is ""[^"\\]*"" better than the two regexes on the line before?
> 
> Regex one matches non-C-strings, it matches include directives for system
> header files, which are preprocessor strings, I can change it.
> Regex two matches a period or something not a double quote, this is
> duplicative.

No, ""(\\.|[^"])*"" matches a backslash-escaped character
(*including* a backslash-escaped double quote) or anything
that is not a double quote, and all that *between* double quotes.

You might change it to ""(\\"|[^"])*"" to remove the duplication
you mention.

> > > "^[[:blank:]]*#[[:blank:]]*(define|(un|ifn?)def|endif|el(if|se)|if|warning|error|pragma)[[:graph:]]*"
> > >   
> > 
> > That you changed [[:space:]] to [[:blank:]] is good.  But why did you
> > add [[:graph:]]* at the end?  What is it supposed to cover?  And why
> > does the patch not remove the earlier line that covers preprocessor
> > directives?
> > 
> 
> So that the colours would go across the whole line, I like it that way.

You like it that way...  But no one else seems to: vim and emacs
and geany and gedit, they all colour what comes after #include
differently from the "#include" itself.  Nano does that too, and
will keep doing that.

> I think we are several different people with multiple very different
> versions of what should be what colour, if it should be coloured and what
> should be coloured, etc.

Right.  So... if you want to propose a change to some of the colourings,
you will have to give good arguments as to why your change improves
things, referring to other editors, to harmony and contrast of colours,
to coherence with other nanorc files...

Benno

-- 
http://www.fastmail.com - Does exactly what it says on the tin