Closed girishji closed 5 months ago
Thanks!
You can refactor any way you want as long as we have these when opt.lspOptions.omniComplete==true
if lspserver.completionLazyDoc
# resolve additional documentation for a selected item
acmds->add({bufnr: bnr,
event: 'CompleteChanged',
group: 'LSPBufferAutocmds',
cmd: 'LspResolve()'})
endif
acmds->add({bufnr: bnr,
event: 'CompleteChanged',
group: 'LSPBufferAutocmds',
cmd: 'LspSetPopupFileType()'})
# Execute LSP server initiated text edits after completion
acmds->add({bufnr: bnr,
event: 'CompleteDone',
group: 'LSPBufferAutocmds',
cmd: $'LspCompleteDone({bnr})'})
You can refactor any way you want as long as we have these when
opt.lspOptions.omniComplete==true
i am not interesting,
if you can confirm there no outage to set those completion settings when it should return
,
then please just re-word that comment,
otherwise please try to fix your issue by "another" way.
https://github.com/yegappan/lsp/pull/426#discussion_r1432741825 https://github.com/yegappan/lsp/pull/428#issuecomment-1868244111
BTW: i still remember last time you modified that kind
.
BTW: i still remember last time you modified that
kind
.
kind
was the correct modification. If LSP server sends you an unexpected response, LSP client should deal with it gracefully. This is not open to debate.
kind
was the correct modification. If LSP server sends you an unexpected response, LSP client should deal with it gracefully. This is not open to debate.
there is a spec, and the kind
value is 1~25 only, client no duty to handle all broken from some server.
wish you were reducing the possibilities of adding odd or wrong code here.
pylsp was not displaying documentation from lsp server. this fixes the problem. user does not have to enable omnicomplete for each file type when main option omniComplete is already enabled.
M autoload/lsp/completion.vim