Re: DOS syntax script

[Pavel Roskin <proski gnu org>]

Hi, Petr!

> > The tradition is that unknown words are not highlighted, the keywords are
> > yellow, not white, and the comments are be brown.  Applied with those
> > changes.
> ok, np (however, brown on blue is not very easy to read - and comments are
> usually the most often read part of code)

I understand this, I'm just trying to keep use the same style across all 
file types, and this style appeared long ago.  I believe this syntax 
highlighting engine was created for Cooledit, a GUI editor that used a 
very dark blue as the background back then, and now uses black by default.  
Brown color used for colors is actually pink in Cooledit.

While porting the Cooledit code to the text mode, color names were added.  
The name is for MC, the number is for Cooledit.  From "man cooledit":

"The colours themselves need to apply to the Midnight Commander internal
editor as well as to Cooledit. Therefore the form
midnight-commander-color/cooledit-color is used. See some of the many rule
sets given, for examples on using this."

brown/22 means brown in mc, pink in Cooledit.  ANSI color terminal
supports only 16 colors, pink is not one of them.

> I know that this could be unimportant topic but: wouldn't it make sense
> to introduce some sort of categories that would be used instead of
> explicit colors ? This could make the higlighting better customizable.
> For instance, I usually use the green color for comments and white for
> keywords; if I had those categories, I would just specify (perhaps by
> changing the config file) that I want to use my customized profile with
> one assignment of colors to categories, and other users could use their
> own or the default. So if this is not too difficult to implement, it
> would be really nice.

It's not hard to implement if we decide to abandon compatibility with
cooledit.  We could use a new "define" keyword, like this:

define $comment cyan/14
keyword rem $comment

Another thing that needs to be done is a better implementation of 
contexts.  Right now, it's impossible to define a context that begins with 
a whole word "rem" and ends at the end of the line.  The keyword "whole" 
affects the newline too, and to be "whole", it should be surrounded by 
spaces or newlines.  Ridiculous and frustrating.

It seems that cooledit is not developed much (just like mc, actually), so 
it should be safe to break compatibility.  However, I would prefer to make 
a stable MC release before that.

-- 
Regards,
Pavel Roskin