VSCode extension overrides config.json options #229
Comments
|
Could you clarify what you have set in your |
|
Due to running in a bazel sandbox, we actually set the It used to be that we could set a non existent path, vscode-zig would complain but at least it didn't override the ZLS options. Now starting https://github.com/ziglang/vscode-zig/pull/222/files#diff-4af55eca91ea0a137b682c0a4f42fc9d6a8a6c56c9484f6974363204fa622f4aR14, because when that happens, that now prevents the whole extension from loading. Same for zls.json {
"zig_lib_path": "/private/var/tmp/_bazel_steeve/3a999f4335ba7d297daf0feac587c784/execroot/_main/bazel-out/darwin_arm64-dbg/bin/third_party/zls/zls.zls_runner.sh.runfiles/rules_zig~~zig~zig_0.14.0-dev.363_Pc3faae6bf_aarch64-macos/lib",
"zig_exe_path": "/private/var/tmp/_bazel_steeve/3a999f4335ba7d297daf0feac587c784/execroot/_main/bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/third_party/zls/zig.zig_runner.sh",
"global_cache_path": "/private/var/tmp/zig-cache"
}
"zig.formattingProvider": "zls",
"zig.initialSetupDone": true,
"zig.zls.path": "${workspaceFolder}/tools/zls.sh",If we disable the formatting provider, the extension loads again but then we lose the formatting, which is kind of a big deal... |
|
The formatting issue should have been fixed by #233. The rest of the issue may be fixed by #252. Could you check whether that resolves your issue? Feel free to wait for the PR to merged and featured in the next release of the extension. I assume that this issue is about zml. I would like to point out that the settings.json should be updated. - "zig.formattingProvider": "zls",
- "zig.initialSetupDone": true,
"zig.path": "${workspaceFolder}/tools/zig.sh",
- "zig.zls.globalCachePath": null,
"zig.zls.path": "${workspaceFolder}/tools/zls.sh",
Not sure how this ties in with bazel and the rest of the project but may even go further and remove - "zig.formattingProvider": "zls",
- "zig.initialSetupDone": true,
- "zig.path": "${workspaceFolder}/tools/zig.sh",
- "zig.zls.globalCachePath": null,
- "zig.zls.path": "${workspaceFolder}/tools/zls.sh",
+ "zig.version": "0.13.0",You can find more information about the version management capabilities of the extension in #230. |
|
I've encountered this issue consistently. It's frustrating to constantly need to troubleshoot why settings aren't taking effect, only to discover that they're being overridden by the extension. Pay attention to
|
This issue should be fixed by fd95050 which has not yet been featured in a new release of the extension. |
|
0.6.5: The extension has an infuriating behavior when setting
OP didn't make it a point, but you can see in their post that |
|
Could you elaborate on whether the logs you have posted are indicating that the LSP is setup as expected or not. I am a bit confused about how there is Apart from the issues I have already referenced here, there is an issue with how editor config and the zls.json work to resolve the zig executable path: Both the ZLS and the vscode extension itself want access to a zig executable. ZLS can be provided a zig executable through the zls.json but the extension has no knowledge of that which means that it will try to find or install a zig executable by itself and then inform ZLS about it. I believe that you and OP have both this issue. To verify I would need to know what exactly is specified in $PATH, zls.json and settings.json.
Is there something concrete that you are missing here? Without more information I could only guess or list all the version management features of the extension. Maybe predefined variables to specify a relative path? Or do just not want it automatically install Zig? |
Yes, the disconnect between them is the issue. My zls.json {
"$schema": "https://raw.githubusercontent.com/zigtools/zls/master/schema.json",
"11zig_exe_path": "/home/rad/Downloads/zig-linux-x86_64-0.11.0/zig",
"12zig_exe_path": "/home/rad/Downloads/zig-linux-x86_64-0.12.0/zig",
"12build_runner_path": "/home/rad/lab/z/zigscient/dev/src/build_runner/0.12.0.zig",
"13zig_exe_path": "/home/rad/Downloads/zig-linux-x86_64-0.13.0/zig",
"3zig_exe_path": "/home/rad/lab/zig/build/stage3/bin/zig",
"zig_exe_path": "/home/rad/lab/zig/build/stage4/bin/zig",
"4zig_exe_path": "/home/rad/lab/zig/build/stage4w/bin/zig",
"enable_build_on_save": true,
"enable_snippets": true,
"enable_ast_check_diagnostics": true,
"enable_autofix": true,
"enable_import_embedfile_argument_completions": true,
"warn_style": true,
"semantic_tokens": "none",
"enable_inlay_hints": true,
"inlay_hints_show_variable_type_hints": true,
"1inlay_hints_show_parameter_name": false,
"1inlay_hints_param_hint_kind": "type",
"1inlay_hints_show_builtin": true,
"1inlay_hints_exclude_single_argument": true,
"inlay_hints_hide_redundant_param_names": true,
"inlay_hints_hide_redundant_param_names_last_token": true,
"operator_completions": true,
"include_at_in_builtins": false,
"max_detail_length": 1048576,
"skip_std_references": true,
"highlight_global_var_declarations": true,
"dangerous_comptime_experiments_do_not_enable": false,
"prefer_ast_check_as_child_process": false,
"analysis_backend": "astgen_analyser"
}I take advantage that unknown fields are ignored, and can quickly switch between zig versions.
My settings.json {
"window.zoomLevel": 2,
"terminal.integrated.env.linux": {
"PATH": "/home/rad/lab/zig/build/stage4/bin:${env:PATH}"
},
"editor.largeFileOptimizations": false,
"update.mode": "manual",
"editor.fontLigatures": false,
"git.openRepositoryInParentFolders": "never",
"editor.minimap.autohide": true,
"editor.minimap.scale": 3,
"editor.rulers": [
80,
100,
120,
140
],
"redhat.telemetry.enabled": false,
"editor.minimap.enabled": false,
"window.titleBarStyle": "custom",
"editor.guides.bracketPairs": "active",
"diffEditor.ignoreTrimWhitespace": false,
"files.insertFinalNewline": true,
"go.survey.prompt": false,
"go.trace.server": "messages",
"diffEditor.codeLens": true,
"terminal.integrated.scrollback": 100000,
"workbench.sideBar.location": "right",
"editor.codeActionsOnSave": {},
"zig.zls.path": "/home/rad/lab/z/zigscient/dev/zig-out/bin/zigscient",
// All nested settings will only affect Zig files.
"[zig]": {
// Formatting with ZLS matches `zig fmt`.
// The Zig FAQ answers some questions about `zig fmt`:
// https://github.com/ziglang/zig/wiki/FAQ
//
// disable format-on-save
// "editor.formatOnSave": false,
// disable inlay hints
// "editor.inlayHints.enabled": "off",
// overwrite words when accepting completions
"editor.suggest.insertMode": "replace",
// The `foldingProviderModel` provides more accurate stick scroll scopes
// "editor.stickyScroll.defaultModel": "foldingProviderModel",
"editor.codeActionsOnSave": {
// Run code actions that currently supports adding and removing discards.
"source.fixAll": "explicit",
// Run code actions that sorts @import declarations.
// Available since ZLS `0.14.0-dev.188+2be424de5`
// "source.organizeImports": "explicit",
}
},
"zig.zls.preferAstCheckAsChildProcess": false,
"zig.zls.debugLog": true,
"zig.zls.enabled": "on",
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
"${env:windir}\\Sysnative\\cmd.exe",
"${env:windir}\\System32\\cmd.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
}
},
"git-graph.integratedTerminalShell": "/usr/bin/fish",
"terminal.integrated.automationProfile.linux": {
"path": "/usr/bin/fish"
},
"zig.zls.warnStyle": true,
"zig.path": "zig",
}Say I'd like to use zig 0.13.0 |
|
Would it no suffice to move the |
Yes, I've arrived at that conclusion 😁 , it was just neater using the .json file when ensuring server functionality with multiple editors. (I guess OP would have to ship a custom/modified/modify settings.json) For completeness sake: the other setting that gets ignored is |
True, that is a nice advantage when using multiple editors. But besides that, based on my personal experience, I've generally had a better time when I removed my zls.json and only relied on editor's configuration. You have to setup some configuration for you editor anyway so getting rid of the zls.json is just one less file that needs to be managed. Many other LSPs only support in-editor configuration as opposed to having their own config file which would make it more consistent.
AFAICT OP is having this issue with the zml project which has a workspace settings.json so it should be possible to set the
This one is kind of intentional. The extension has "partial" as the default value for |
Hello
If ZLS is started with a custom
config.json, unfortunately the extension will override the settings when sending its configuration.Perhaps it could be possible to only send the keys that are set by the user ?
Here is a sample log:
Thank you for this great extension !
The text was updated successfully, but these errors were encountered: