bollwyvl
commented
2 years ago Sure, I guess if it's what we need.
Some questions for discussion:
- is the any reason we'd not want to blanket allow filtering any message?
- we could probably do some filter-by-example thing
- at present, we only block if there are listeners
- practically (because of the first-party
virtual) there always is
- practically (because of the first-party
- we should probably (optionally) enable using a better JSON parser than stdlib
- should we offer rewriting at the same time, or still hold off on that?
- i really see that as a way some extenders might do some seriously un-user-friendly things. sigh.
- would this be a new version of the listener API/entry point?
- would we continue to support/use the old one for a while?
krassowski
What are you trying to do?
While nice language servers perform server-side filtering of completion items, the LSP protocol itself does not make it mandatory; moreover the long-standing request to make it part of the protocol (https://github.com/microsoft/language-server-protocol/issues/898) was closed in October and will not be enacted.
How is it done today, and what are the limits of current practice?
Currently we do not filter the response to the initial request after trigger to match the current token:
This means thousands of irrelevant completion items and delay in rendering of completer list for servers which do not filter on the server side (like
typescript-language-server).What is new in your approach and why do you think it will be successful?
https://github.com/microsoft/language-server-protocol/issues/898#issuecomment-593968008 describes how clients should behave (and how they should not filter completion items with text edits).