Open PowerUser64 opened 1 year ago
Which client/editor are you using?
The bash language server is actually provides the error code and URL to the wiki — most clients show these.
We should add code fixes for disabling failing shellcheck rules though by inserting a comment above the failing line.
Which client/editor are you using?
I'm using neovim.
The bash language server is actually provides the error code and URL to the wiki — most clients show these.
Interesting, I might be able to hack the codes into the display somehow with neovim, or add a key map to disable the code.
We should add code fixes for disabling failing shellcheck rules though by inserting a comment above the failing line.
This would be a very welcome solution. It's worth noting that shellcheck codes can be disabled on a per-line, per-scope, and per-file basis, depending on where the comment is placed (above the line, before the scope, and at the top of the file, respectively). It's probably most important to support disabling codes for the entire file, but these other options may also be worth implementing at some point.
You can include the error code with the following init.lua
configuration
local diag_format = function(d)
return string.format("(%s) %s", d.code, d.message)
end
vim.diagnostic.config({
virtual_text = {
format = diag_format,
},
float = {
format = diag_format,
}
})
I do have the exact same problem - the codes are gone - and this used to work. I haven't changed anything lately on my IDE configuration.
I'm using Neovim (actually lunarvim). For testing purposes I switched to an out of the box LunarVim config and I still do not see shellcheck error codes with bashls.
The LSP is setup using Mason, bashls 4.8.3 is installed. LunarVim 1.2 running with Nvim v0.8.3. The screenshots below are made with a stock lvim-1.2 configuration with no further changes. Relevant LSP configuration done by lvim can be seen here:
As you can see, it would display an error code if there was one.
@mrolli the LunarVim config you linked to sets the format for the float, but in your screenshot you show the virtual text. You could try setting the virtual text format as in my previous comment.
@shanesmith Thank you for pointing me to the fact that there is virtual_text and float. I added your code at the very end of my config, but it does not have an effect. I assume that lvim is overwriting this at a later stage. I have to learn how to change these things "the lvim way of doing".
But, to add to the previous discussion: In my case, the local quickfix list is filled with diagnostic information that actually shows the shellcheck code in addition to the the textual representation:
So, it's safe to state the (at least in my case), bashls does the right thing.
@mrolli Same here, similar setup (Neovim / Mason / bash-language-server 4.9.0) except I'm not using any pre-made config for Neovim
https://github.com/bash-lsp/bash-language-server/issues/752#issuecomment-1462435681 doesn't make any difference either for me, not sure why.
Edit: nevermind, I got it working:
virtual_text = false
was already set somewhere in my dots so it was overwritten.
@xfzv well as @shanesmith pointed out, you have to set the virtual_text property
For me with LunarVim, I ended up with the following that worked:
lvim.lsp.diagnostics.virtual_text = {
format = lvim.lsp.diagnostics.float.format
}
Here I set the format option of the virtual_text to the same value as the format option of the float counterpart. Apparently these settings are prepared and later handed over to vim.diagnostics
. So this is a "timing"issue, maybe someone else can help and enlighten us where to put it in order to have the right timing for vim.diagnostics
to pick it up.
@xfzv well as @shanesmith pointed out, you have to set the virtual_text property
For me with LunarVim, I ended up with the following that worked:
lvim.lsp.diagnostics.virtual_text = { format = lvim.lsp.diagnostics.float.format }
Here I set the format option of the virtual_text to the same value as the format option of the float counterpart. Apparently these settings are prepared and later handed over to
vim.diagnostics
. So this is a "timing"issue, maybe someone else can help and enlighten us where to put it in order to have the right timing forvim.diagnostics
to pick it up.
Thanks for the reply! I got it working, see my edit.
Another similar setup here (Neovim / Mason / bash-language-server 4.9.1).
The comment above resolved my issue as well, but still got a small question:
It seems that the error code is presented by default in the floating window (vim.diagnostic.open_float()
, the [SC2168]
in white) but not in the virtual text. Is it possible to align the behavior for the virtual text also?
(so back to the original issue essentially)
Got similar issue in the case of Eclipse ShellWax #865 missing shellcheck SCxxx prefix in "message" attribute.
It seems that BLS API was broken at some release after 3.1.0.
What is the problem this feature will solve?
There are quite a few shellcheck errors that I want shellcheck to catch but I don't want to correct them in all scenarios. In order to tell shellcheck to ignore an error, you need to add a comment that looks like this:
# shellcheck disable=SC2048
. The only problem is this number is removed by bash ls, so I have no way of knowing what shellcheck code to disable.What is the feature you are proposing to solve the problem?
Please don't remove the
SC####
codes - I want to know them so I can disable warnings I don't want to fix.example of a warning I don't want to fix:
What alternatives have you considered?
The alternative is you run shellcheck on its own to see what the code is, then copy paste the code into the
shellcheck disable
comment, but having to run shellcheck externally defeats the purpose of shellcheck integration.Another thing is you can have a shellcheck rc file that provides a list of codes to always disable, but I don't want to have codes always disabled. I want shellcheck to keep me from messing up but I also want to be able to turn off errors so I don't have superfluous errors in my code. Not to mention that building such a file requires knowing the codes to begin with, which brings me back to my first point.