Contains all the functionality for the highlighting, is going to get cleaned up a lot though. Might end up wanting to create a color theme as well, none of the default ones are that great with this...
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 36018 Build 36017: arc lint + arc unit
Event Timeline
Fixed bug that made it impossible to find colors that were a perfect match to the scope we are looking for (ex: fixes function being color as functions and not as entity.name)
Explanation for the bug: When adding the function highlighting definition the fully qualified name "entity.name.function" was added to a separate list that we did not try to match partial scope matches to.
clang-tools-extra/clangd/clients/clangd-vscode/src/TextMate.ts | ||
---|---|---|
21 | I'm pretty sure this matching logic is wrong. An example of the scopes for variables in the Light+ theme: variable.css variable.scss variable.other.less variable.language.wildcard.java variable.language storage.type.variable.cs variable meta.definition.variable.name support.variable entity.name.variable With this kind of matching we have now this means that variable.other.less will match variable.other and variable.other.less. What should probably be done is remove the divided map. The query function should still be the same but query on this.colors instead of this.divided. |
clang-tools-extra/clangd/clients/clangd-vscode/src/TextMate.ts | ||
---|---|---|
21 | The suffix of textmate indicates the language it belongs to (e.g. java), I think we can ignore non-C++ textmates, and merely find the longest-prefix match in all c++ textmates? |
clang-tools-extra/clangd/clients/clangd-vscode/src/TextMate.ts | ||
---|---|---|
21 | But we have no real way of knowing if a suffix is a language or a more "precise" scope. The implementation I changed to just saves the full scopes and than when we try to find the color of a scope we try to find it in the map, otherwise remove a suffix and try to find that scope (over and over) Ex: Find scope for variable.other.field.cpp -> First check for `variable.other.field.cpp` (finds nothing) Check `variable.other.field` (finds nothing) Check `variable.other` (still finds nothing Check `variable` (finds the variable scope and returns that color) This seems to work, but maybe there's some case I miss. Anyway, there is probably a defined order on how you are supposed to find these scopes, I think I read a blog post on how VSCode actually does this matching internally. I'll try to dig that up and make sure our implementation matches before it's time to put up the actual CLs for this. |
Do you plan to support text decoration options other than color, e.g. bold / underline / italic?
Are users going to be able to change the color (and other decoration options) for specific highlightings in the VSCode Settings?
I think we'd just support color, and we don't have further plan to support richer renderings at the moment -- ideally, vscode should have built-in support for semantic highlighting if the proposal is accepted in LSP, this means this part of extension code will be removed in the end.
Are users going to be able to change the color (and other decoration options) for specific highlightings in the VSCode Settings?
vscode seems to provide a mechanism to override the theme settings, like
"editor.tokenColorCustomizations": { "[Visual Studio Dark]": { "textMateRules": [ { "scope": "entity.name.type", "settings": { "foreground": "#FF0000", } } ] }
I think our extension should respect it.
I'm pretty sure this matching logic is wrong. An example of the scopes for variables in the Light+ theme:
With this kind of matching we have now this means that variable.other.less will match variable.other and variable.other.less.
As there is no perfect match for variable.other.field it will try to match variable.other and find the color for less.
What should probably be done is remove the divided map. The query function should still be the same but query on this.colors instead of this.divided.