We should enable filtering completion items after trigger

[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 (microsoft/language-server-protocol#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?

microsoft/language-server-protocol#898 (comment) describes how clients should behave (and how they should not filter completion items with text edits).

[bollwyvl]

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
  • 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]

We do not want to filter messages - we want to filter things shown in the completer; this is to allow instant completions from cache (this is discussed upstream in LSP repo and I outlined changes we need upstream in JupyterLab in jupyterlab/jupyterlab#9763 (comment)). The initial hotfix for the typescript situation is in #735 - it is sufficient for now because we do not use textEdit just yet, but it is not the ultimate solution.

[krassowski]

It does not preclude filtering messages - just not useful here because we want to have all completion items cached on the frontend.