Change handling of incomplete completion lists

[FlorianKroiss]

PR #906 introduced a pseudo completion item, which is added when a completion list is marked as incomplete.

We recently discovered a bug (#1448, Platform.UI ) , whose impact is massively worsened by this behavior, so I'd like to make a few points against adding this pseudo entry:

1. I don't think that the information encoded in CompletionList.isIncomplete is intended to be shown to the end-user. The spec says:

for speed clients should be able to filter an already received completion list if the user continues typing. Servers can opt out of this using a CompletionList and mark it as isIncomplete.

So the flag is only intended to tell the client (not the user) that it cannot re-use and filter the received completion list if the user types more characters, but has to ask the server again for a fresh completion list.

2. If you are working with a LS which is setting this flag, e.g., basedpyright, then you get this annoying behavior on every typed character:
   https://github.com/user-attachments/assets/26799104-597f-4a00-976f-8268dbfe2208
   This is also making the bug in Flickering hover popup on mouse-over #1448 incrementally worse.

3. Other LS Clients, e.g., Theia or VS Code do not behave this way, i.e., they just don't open a completions popup at all if the returned proposal list is empty:
   https://github.com/user-attachments/assets/a6a40b9a-3ca8-4b8e-a1fe-05fcd2116f33

@andrewL-avlq, since you added the behavior in the first place, do you still recall your use-case?

Since I don't want to break the workflow of other LSP4E users, here are a few ideas to make this less of a problem:
Ordered from least to most invasive.

1. Add a preference to configure if the pseudo proposal should be added
2. Only add the pseudo-proposal if the list is not empty.
3. Don't add the pseudo proposal at all (basically revert Indicate when content assist proposals are incomplete. #906) , to make LSP4E follow the Spec more closely and behave similar to other LSP Clients (My preferred solution, but likely not feasible and breaking the use-case of @andrewL-avlq)

Thoughts?

[rubenporras]

Hi @FlorianKroiss ,

the use case is the following, the user types a, the server returns an incomplete list with some elements, let us say (abc, ade, afg), all starting with the letter a, in a place where the user knows for a fact that ahi is available, so he will wonder why ahi is not in the list. He cannot know that he must type h for the server to return more elements if he does not know that the list is incomplete.

We had this problem reported by users because our server needs to return in some cases very big lists, and the users where indeed complaining that they could not find the elements they were expecting. The same problem appeared if the user would force content assist with Ctrl-Space instead of typing some letters. Adding the indication solved the problem for our users, we never got questions again.

I think we can go for

2. Only add the pseudo-proposal if the list is not empty.

Would you like to create a PR for that?

Regards

[FlorianKroiss]

Ok, I can see why it it was implemented like that. I will create a PR

[FlorianKroiss]

Closed by #1471