#1505 INDIC_TEXTFORE_BOLD indicator style

[Jiri Techet]

Some LSP servers provide the "semantic token" functionality - for ranges in a document, they return what these ranges are - a type, number, comment, string, etc. This mens, functionality-wise, this feature kind of overlappes with what Scintilla lexers do.

While it doesn't make sense to use these for the functionality provided by Scintilla, this feature is interesting for providing colorization of types (such as class, struct and typedef names) which Scintilla is not aware of.

One way of providing this functionality is to get the words at the ranges provided by LSP semantic tokens and inject these words to Scintilla using SCI_SETKEYWORDS. But this is only possible for type keywords like e.g. the CPP lexer has but not all lexers provide enough keyword lists. This method also isn't perfect because if Foo is defined as a type in the file but then Foo is used as a variable, this Foo variable will be incorrectly colorized as a type.

I experimented using INDIC_TEXTFORE indicators to hightlight types at the ranges provided by LSP servers and it seems to work, see:

https://github.com/techee/geany-lsp/issues/18

The only problem is that these cannot be displayed in boldface and we'd need something like INDIC_TEXTFORE_BOLD. Would it be OK to add something like that to Scintilla? Or is there some better way to highlight some words in a document at certain ranges? I've tried using

https://www.scintilla.org/ScintillaDoc.html#Styling

but these seem to clear the styling made by lexers so they don't seem to be suitable for this use case.

[Neil Hodgson]

Adding bold to a style changes (widens) the layout and INDIC_TEXTFORE relies on the layout remaining the same when just changing colour. Therefore INDIC_TEXTFORE_BOLD wouldn't work well.

[Jiri Techet]

Ah, pity. In any case, from the LSP servers I tried only clangd supports these "semantic tokens" and there one can feed the keywords using SCI_SETKEYWORDS so it's probably not so critical for now.

[Neil Hodgson]

There are conflicting directions with expression and dynamicity versus performance and stability. Scintilla has settled on two 'phases': lexing and fold recognition produces a fixed layout which can be decorated with changing light-weight indicators.

There could be more than one lexing operation in the lex+fold phase but co-ordinating it with the current lexers is difficult. If style bytes are set by a secondary lexer then that will confuse the main lexer that believes it completely controls styling. Secondary lexers could produce a sparse style overlay but that then has to be integrated into the drawing pipeline and communicated with applications. If there were secondary lexers then there'd probably be calls for multiple.