If you mean things like `lexer.cpp.track.preprocessor=0` then no, it can be done dynamically in the config file independently of highlightingmappings.h.
But for that, the user of geany has to know source code of lexilla :-( From the beginning of use of geany, I miss some function to let me show, what wordlists, sytles and porperties are available for configuration within config files.
But if a new highlighting style is introduced by a lexer, Geany indeed has to update `highlightingmappings.h`. I think the reason for this was to have nice names in the config file like e.g. `commentline` for Python instead of `style.python.1` in SciTE but this is at the cost of some extra maintenance. But it's probably too late to change that for all the languages.
see https://github.com/ScintillaOrg/lexilla/issues/296, just created
lexer Pascal has properties lexer.pascal.smart.highlighting fold.comment fold.preprocessor and fold.compact Geany does use lexer.pascal.smart.highlighting (in filetype.pascal lexer.pascal.smart.highlighting=1), but in highlightingmappings.h there is entry #define highlighting_properties_PASCAL EMPTY_PROPERTIES.
That's alright. In general, properties should be defined in the config file instead of being hard-coded.
For all of this, user has to know, which properties are available, what means again he has to read source of Lexilla.
:
lexer CPP currently has defined 6 keyword lists. In highlightingmappings.h there is entry only for 0 primary 1 secondary and 2 docComment. The drawback extends deep into the source code. For example, here geany uses wordlist 3:
Basically I think nobody from Geany developers (or even users) needs 6 keyword groups so only 3 are defined. If there's a need, we may add more.
This let me fret about my needs. I've been working on some kind of universal lexer, supporting some dozen of styles and word lists. Did I miss soming? Your statement makes me hesitate to finish it for publication.