Change global variable token to definition
Fixing the issue: https://github.com/LuaLS/lua-language-server/issues/2646
The TokenModifier global isn't is a default token to vscode documentation (doc). This change will set the default global colors to a different color from local variables. The token static is another option, but some themes don't define this color too.
Using for a time this change i noticed an improve in coding from my team, because this avoid some word misstakes and they can visually check if they write some variable wrong. And they don't need to change any configuration inside the vscode to define "global" in any theme.
Maybe this can fix a related issue for requesting to differentiate between local and global variables as well: https://github.com/LuaLS/lua-language-server/issues/2880, since in this PR it uses different colors for them by default.
I just checked out this PR locally, I notice that now the global tokens are changed to variable.definition type instead of variable.global, and have a different default color.
However in the theme that I used (One Dark Pro), the default color of variable.definition is the same of class and self, so now they just collided with another variable type instead of local variables. 😅
Is this the expected outcome? 🤔 Since currently self is also of type variable.definition, that means I CANNOT use a rule to differentiate between self and global variable... In the case before when they are variable.global, I can still use a rule to distinguish them, as mentioned here: https://github.com/LuaLS/lua-language-server/issues/2880#issuecomment-2388181534
edit:
Oh~ I just found that you already proposed to change self to variable.static or variable.readonly in your original issue 👀
"variable.definition" is used in self, so if it will be accepted the suggestion is change self to "variable.static" or "variable.readonly"
I think readonly is a good setting to use too. And you can diff from the self variable. I will change the PR.
I use the theme "Dark Modern" and the colors will be
In the One Dark Pro theme that I used, both readonly and definition have the same color. 🙈
And semantically, a global variable doesn't mean readonly. 🤔
Moreover variable.readonly will collide with _ENV and variable with <const> keyword
A = {} -- `A` is `variable.readonly`
local a<const> -- `a` is `variable.readonly`
print(a) -- `a` is `variable.readonly`
_ENV = nil -- `_ENV` is `variable.readonly`
=> they all have same colors now and no way to distinguish them 😇
The TokenModifier global isn't is a default token to vscode documentation (doc).
I understand global modifier is non standard, but after some googling I found out that vscode-cpptools is also using global modifier for global variables: https://github.com/microsoft/vscode-cpptools/issues/4992
Only with a new global modifier, then we are specifically theme a global variable with its own color 🤔
Furthermore I just read the vscode doc you provided, seems an extension can create a custom textmate scope mappings for fallback theming: https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#custom-textmate-scope-mappings
Maybe another approach is to map variable.global to variable.readonly something like that in the vscode-lua extension?
https://github.com/LuaLS/vscode-lua/blob/34c70bbda7de10664e2681ccd1f08940ebc73d34/package.json#L3377-L3379
In this way:
- luals (the server itself) can provide the most accurate modifier type (global)
- users (like me) can theme
variable.globalspecifically - and fallback type
variable.readonlyis provided, such that normal users by default already have different colors for global and local variables 😄
@comedinha
Hi, I just tested modifying the semanticTokenScopes in package.json of vscode-lua extension locally
- by changing the fallback value of
variable.globalfromvariable.global.luatovariable.other.constant.luahttps://github.com/LuaLS/vscode-lua/blob/34c70bbda7de10664e2681ccd1f08940ebc73d34/package.json#L3377-L3379
"variable.global": [
"variable.other.constant.lua"
],
-
it can achieve the same result as using color as constants, while preserving the
variable.globalmodifier -
And I can still use custom
variable.global:luarule to theme it specifically, without modifying the color of other constants:
"editor.semanticTokenColorCustomizations": {
"[One Dark*]": {
"rules": {
"variable.global:lua": "#E06C75",
},
},
},
In short I believe this would be a better approach for defaulting the color of global variables, rather than directly changing its token type sent from LuaLS 👀
edit: after doing some git blame on vscode-lua repo, this variable.global is added by author purposely 🤔
- originally he used
variable.statichttps://github.com/LuaLS/vscode-lua/commit/dd88c4437c6791f43b39a68b14c7508c95f3ea06 - and later he changed to
variable.globalhttps://github.com/LuaLS/vscode-lua/commit/cabcdeb8948fdb74f677d7faf3b957726e657046 - With this fact, I don't think author would like to rollback the modifier sent from LuaLS to
staticorreadonly. And modifying the fallback textmate scope in the vscode extension's side would be a better approach.
Rendering code is not limited to semantic tokens; in fact, it can also be done using a custom protocol in VSCode with vscode.TextEditor.setDecorations. This rendering can override the limitations of the theme itself, providing more flexibility and stronger visual effects.
Rendering code is not limited to semantic tokens; in fact, it can also be done using a custom protocol in VSCode with vscode.TextEditor.setDecorations. This rendering can override the limitations of the theme itself, providing more flexibility and stronger visual effects.
I will check this way. I work with many people who won't configure VS Code by themselves. This change needs to be global for me because I can't teach everyone and new coworkers how to configure their editor. They just open the folder, and all LuaLS settings are automatically set.