Skins to override editor syntax highlight colors

[egmont]

Skins have complete control over mc's and mcview's colors, and can specify mcedit's basic colors, too. However, they have no control whatsoever over mcedit's syntax highlighting.

In ticket #2169 I've just recommended a dark-on-bright color scheme (kind of making it a "noon commander" instead of "midnight commander" :-)). However, the yellow foreground color used by many syntax definitions is quite unreadable. Moreover, once that skin is using 256 colors, I might want to leverage these colors in the syntax highligher too.

Here's my recommendation on how to improve the situation.

Currently syntax files have a direct mapping from individual keywords to colors. Example (from c.syntax):

keyword whole if yellow
keyword whole else yellow
keyword \* yellow
keyword \+ yellow
keyword ( brightcyan
keyword ) brightcyan

It perfectly makes sense to force "if" and "else" to have the same color, and to have "+" and "-" to have the same one. I assume it's safe to assume nobody would want to do differently. However, "if" and "+" should not necessarily be the same colors.

I recommend introducing a level of abstraction between the exact keywords and the colors: the type of the token. Syntax files already support the "define" keywords, it's just not being used right now. The snippet above could be modified as this:

define builtinkeyword yellow
define mathoperator yellow
define parenthesis brightcyan
keyword whole if builtinkeyword
keyword whole else builtinkeyword
keyword \* mathoperator
keyword \+ mathoperator
keyword ( parenthesis
keyword ) parenthesis

So far no code change is required, only some refactoring in the syntax files.

As the next step, skins could optionally override the value of any "define" statement. Example fragment from such an imaginery skin file:

[c.syntax]

mathoperator=green
parenthesis=black;white

[php.syntax]

blah=gray
etc...

Skins that choose to override some colors would still have to cooperate a little bit with the syntax definition files in order to use the same token type names, but at least they wouldn't have to duplicate the complete syntax file, or the list of the language's keywords again.

A little bit of magic is required wrt the separator character: in skin files it's the semicolon, in syntax files it's whitespace, and I'm afraid colors is not the only thing you can use a "define" for. Probably the cleanest is to modify the syntax file parser to accept ';' as an alternative to whitespace. Or, to introduce a new keyword "color" which acts similarly to "define", but can only be used for colors and attributes, and allow skins to override "color"s only, not "define"s.

[zaytsev]

I don't like this proposal for the reason that syntax highlighting is not only used for languages proper. E.g. I can enjoy reading highlighted mailbox files, ini files and other weird text files. Your suggested abstraction will not fit all the syntaxes without becoming incredibly complicated, redundant and confusing.

Why not just use 256 colors in the syntax definitions as is? I would actually prefer this route if only there's a way to provide a fallback that prevents changes in the behavior for 16-color users.

[zaytsev]

Ah wait, I guess I now get your point about the defines. You want to define these keywords per syntax, so e.g. for mbox syntax I can define headers as a keyword and use it instead of the specific color later in the definitions.

If this is the case please disregard my comment above.

[egmont]

Yep, correct. It would be up to the individual syntax file to define any keywords, and mc's skin engine would dynamically match them to whichever keywords are present in the skin file.

The point is (no matter if 16 or 256 colors): currently yellow is heavily used as foreground color, making it impossible to create a skin with white (or any bright) background (as yellow on white is unreadable). It would be nice if somehow skins could not only say "let's make the background white" but also "and let's change the yellow foreground to blue".

I'm not sure this is the best possible approach, it's just an idea. Maybe we should look how other applications (e.g. vim) address this problem - I really have no clue.