fix: current buffer for lsp.start #506
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Quote from
vim.lsp.start()
docs:Using
vim.schedule_wrap()
in FileType autocmd result in callingbuf_attach()
(and thusshould_attach()
andvim.lsp.start()
) always on current buffer instead of buffer triggered FileType autocmd.I've also removed unconditional call to
buf_attach()
at the end ofsetup()
because it looks like an incomplete support for lazy loading (a complete support should take in account there may be more than one buffer at this moment).This can be fixed in a different way (by remembering
bufnr
in FileType autocmd and then usingvim.schedule
to runbuf_attach()
with givenbufnr
), but this is much more intrusive change because it will need the whole chain of involved functions to accept and use extra parambufnr
instead of working with a current buffer. Also adding support forbufnr
param might result in possibility to re-enable lazy loading support. It may worth to implement later - please consider this PR a hotfix for security issue (prevent attaching to buffers with sensitive files).Fixes #504