@b4n commented on this pull request.

{

- g_warning("Failed to find lexer for ID %u", lexer_id); + g_warning("Failed to find lexer for name %s", lexer_name);

I don't know how expansive it'd be indeed, so whether or not it's reasonable to do it, but we could check. From a quick look, it'll perform a linear search for the lexer of that name, and call Create() on the module, which either calls the lexer's `LexerFactoryFunction` (calling lexer code, which normally would instantiate an instance of the relevant lexer), or instantiate a new `LexerSimple`. So… it seems to be in between cheap and expansive, but I didn't profile anything.

2. We'd need to iterate through all lexers. Right now all lexers have to be mentioned explicitly at 2 different places in switches in `highlighting.c` and we probably don't want to add one more. So we'd have to create a table containing all the lexers, possibly in a similar way like in `filetypes.c`.

I was wondering whether, now that we use a name for the lexers, if we'd want to avoid hard-coding things in highlightingmappings.h and move that to the filetypes files à-la-SciTE? E.g. maybe something like this:

``` [lexer] # could also be e.g. in [settings] as lexer_name name = cpp # style[lexer style number] = style name for use in [styling] styles[0] = default styles[1] = comment styles[2] = commentline styles[3] = commentdoc # … # keywors, those could possibly use GetWordListDescription() or similar to have actual names keywords[0] = primary keywords[1] = secondary keywords[2] = docComment # … ```

or if we were to break compatibility, we could avoid adding a proxy and just use the style/keyword numbers directly instead of mapping them twice..

I don't particularly like the idea of having arbitrary numbers there, but in the end, is it worse than the internal tables? And maybe we could use `NamedStyles()`/`NameOfStyle()` and `DescribeWordListSets()` if enough lexers we need support that.

Anyway, it might not be relevant as we're not loading all filetype files anyway.

But note that any list to check would have to *actually* be synchronized with what is used; the issue in #3616 would only be found if checking the ID we *used*, not the list of lexers we *had*, as it was missing from the `AddLexerModules()` call.

@b4n pushed 1 commit.

1009e021c39bb116e77f007ec4e59d7fb64fc8a6 Use Scintilla lexer names rather than deprecated IDs

@techee commented on this pull request.

{

- g_warning("Failed to find lexer for ID %u", lexer_id); + g_warning("Failed to find lexer for name %s", lexer_name);

To avoid speculations regarding the speed of creation of all lexers, I created #3673 testing it (less than 2 ms on Raspberry Pi 4). So I don't think we have to worry about speed here.

…and you could check this patch using this:

Wizardry :-)

@b4n commented on this pull request.

SSM(sci, SCI_SETILEXER, 0, (uintptr_t) lexer);

- if (old != (gint)lexer_id) + if (old != sci_get_lexer(sci))

I'm not sure what is the recommendation on this: the [documentation](https://scintilla.org/ScintillaDoc.html#SCI_SETILEXER) says to use this for checking whether setting the new lexer worked. OTOH, there is [SCI_GETLEXERLANGUAGE](https://scintilla.org/ScintillaDoc.html#SCI_GETLEXERLANGUAGE) which probably would work as well (albeit a bit more expansive).

@b4n commented on this pull request.

SSM(sci, SCI_SETILEXER, 0, (uintptr_t) lexer);

- if (old != (gint)lexer_id) + if (old != sci_get_lexer(sci))

OK. I can easily use this here (seems to work), but porting every use in Geany is gonna be more tricky, especially for cases like `highlighting_is_*_style()`

Thank you, but my intended point was that it should be done offline before release (if not in CI), not when being used by a user, thats too late.

Yeah, but that would happen. If we do it every time Geany starts, it will also happen for unit tests because these too launch the Geany binary, and of course the developer who is updating to a new version of Scintilla will see it too because Geany will just refuse to start.