> For me, that's a great drawback of geany vs. lexilla source code. Every time > any lexer feature is added to lexilla, highlightingmappings.h needs to be > updated manually, keeping order troublesomly. I'm not sure, but even now, > there are differences.
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 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. > Examples of discrepancies: Not discrepancies IMO, see below. > 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. > lexer CPP has about 20 properties defined. Two of them are used in geany (in > filetype.c styling.within.preprocessor=1 and lexer.cpp.track.preprocessor=0), > but in highlightingmappings.h there is entry "fold.cpp.comment.explicit", "0". And if users wish, they can add whichever of those 20 properties to the config file and customize the lexer to their needs. I don't know why `fold.cpp.comment.explicit` is hard-coded - possibly some things in Geany don't work if this property is set to 1. > 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. The wordlist 3 is indeed "magic" as it serves for injecting types from ctags to Scintilla and their colorization. If I'm not mistaken, we do this only for a few languages now, mostly using the C lexer so there hasn't been much need to define it dynamically. > I propose to introduce keywordlist constants: SCE_[LANG]_K_[DESCRIPTION] and > rename existing style constants SCE_[LANG]_[DESCRIPTION] to > SCE_[LANG]_S_[DESCRIPTION]. Keywordlist constants can be used in > highlighting_keywords_[LANG] and in source code (e.g. in document.c, see > above) and will improve readability and reduce fault liability SciLexer.h: > SCE_C_K_GLOBALCLASSESANDTYPES = 3; and document.c: keyword_idx = > SCE_C_K_GLOBALCLASSESANDTYPES;. If you want such a change, you must do it in Scintilla - "SciLexer.h" isn't our code and as I said, it's generated dynamically using a script in Scintilla. I slightly doubt it will be accepted though. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/discussions/4154#discussioncomment-11627687 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/repo-discussions/4154/comments/[email protected]>
