Closed jsatt closed 2 years ago
@jsatt currently lspsaga just support jump diagnostic. and all diagnostics form vim.lsp.diagnostic.get
function. so use vim.diangositc.config
should be work .
Interesting, it doesn't seem to be working that way for me at the moment.
I just reinstalled the latest changes this morning (cd26b52) and pulled my Lspsaga config back to just require('lspsaga').init_lsp_saga()
and this is my diagnostic config
vim.diagnostic.config {
signs = {
active = signs,
},
update_in_insert = false,
underline = true,
severity_sort = true,
virtual_text = {
source = true,
},
float = {
focusable = false,
style = "minimal",
border = "rounded",
source = true,
header = "",
prefix = "",
},
}
However when I use lspsaga to jump to the next diagnostic I see the error without the source.
but using vim.diagnostic.open_float()
it displays the error with the source.
I'm running neovim 0.7.0 from the appimage on Ubuntu 20.04.
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wsuggest-attribute=pure -Wsuggest-attribute=
const -Wsuggest-attribute=malloc -Wsuggest-attribute=cold -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/in
clude -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az316-460
Features: +acl +iconv +tui
My full nvim config is available in this repo if it's helpful and I'm happy to provide any other info.
Okay got it. I will test. and I am wonder why your pics1 miss color. it should be red:)
Yeah I was kind of wondering the same, but I was just taking one issue at a time. Could be related to something else in my config, but I feel like I've narrowed down the stuff that I would expect to affect saga.
check hi DiagnosticError
. and hi LspSagaDiagnosticError
@jsatt now support config diagnostic source .
So I see the it includes the source now, which is the main thing I was looking for, but it still doesn't seem to respect the vim.diagnostic.config. It's now showing the source at all time regardless of if the float.source is true or false.
Also, placing it in the header brings to mind the question of multiple diagnostics on the same line, but maybe this should just be a separate ticket. Since the current jump to next/prev only displays one diagnostic at a time, but using the jump to next/prev also only seems to be jumping to the next line with a diagnostic, not the next diagnostic (ie. skipping the other diagnostics on that line).
The coloring issue is definitely related to those highlights not being set as expected. I'll look into what's up my theme, but it's not anything in the plugin.
Oh, I just saw in the commit that you added a new config option. I think that's probably fine for managing it that way, really as long as it's configurable. Using that to configure works as expected.
now move the source into the content not in title.
and other options, they are config the sign and virtual text. it's work in builtin. saga just deal with jump or show line/buffer diagnostics in future.
signs = {
active = signs,
},
update_in_insert = false,
underline = true,
severity_sort = true,
virtual_text = {
source = true,
},
The built-in neovim diagnostic tooling allows customizing the diagnostic messages (using vim.diagnostic.config()) that appear in the virtual text and floating window. These options include displaying the
source
(which tool generated the message), aprefix
which can be added to the message and aformat
function which allows users to access the diagnostic object tables for complete control over the message. It appears that the Lspsaga implementation is hard coded to only show the message.It would be ideal if Lspsaga respected these builtin settings as configured. Short of supporting the builtin formatting, Lspsaga should at least provided some similar options within it's own setup to customize the messages.