Support snippet-less completion

[matklad]

Some clients don't support completions snippets. It can be argued that clients generally should be improved to support snippets, but

• I can imagine embedding rust-analyzer in the contexts where full snippet support does not make sense (for example, completion in the eval field of a debugger)
• I can imagine some users might prefer simple identifier completions

So, we should support this use-case. Specifically, we should only send snippet completions if supports them.

A simplest fix here (and a good initial implemtation) is change code around here to just strip $i snippet markers from text edit, if the client doesn't support snippets. A similar "fixup" approach is used for folding ranges.

However in general it seems like the core completion engine should just provide different completions depending on whether snippets are enable or not. This should be done via feature flags (example), and requires some design to make sure that we don't twice as much code, but still provide best possible completions with and without snippets.

[bstaletic]

Thanks for opening this issue. As mentioned in #1705, not providing plain text completion is a protocol violation, so "clients should be improved" is not a valid statement.

Some clients don't support completions snippets. It can be argued that clients generally should be improved to support snippets

As a maintainer of such a client and someone with a strong opinion that goes against snippets, here's my .02c:

I'm a vim user. Snippets in vim are expanded on something called CompleteDone event, which is triggered whenever something closes the completion menu. That can be ctrl-y, which works fine with snippets and simply closes the menu. However this completely breaks my workflow. I'm used to just continuing to type after selecting a completion. If I hit enter instead, the new line is entered before the snippet is expanded, which messes up a lot of things and to work around this is incredibly tricky (speaking from the client maintainer's point of view). So I have two options if I want to use snippets:

• Break my workflow in favour of a less efficient one.
• Put much more work than I think it's worth, for a feature that I would still find bad.
  • That's because with plain text completion, I know ahead of time what text will be inserted. This is again, very important for my workflow.

So the instead, ycmd maintainers, unanimously, settled for a third option - not implementing snippets.

However in general it seems like the core completion engine should just provide different completions depending on whether snippets are enable or not.

So, I haven't looked at the rust-analyzer code, but a client like ycmd would expect foo insertion text for a foo(/* any amount of args */).

 

Now I didn't mean to sound harsh, in case I did. It's just that a lot of servers assume snippets are supported, even though it can be argued that they provide a pretty horrible user experience.
On a side note, my workflow is basically the workflow of all ycmd users, so drastic changes like snippets could very much be more harm than good, considering that ycmd is much older than LSP.

EDIT:

A simplest fix here (and a good initial implemtation) is change code around here to just strip $i snippet markers from text edit, if the client doesn't support snippets.

Would that make insertion text just foo()? That's something ycmd can work with, but it's less than idea. The Apple's Swift server, when used with a client that doesn't support snippets, just strips ${}, but leaves the test in between { and }, i.e. it returns foo(int bar). This forced me to override the completion algorithm and strip everything after the first (. Like I said, workable, but not ideal.

[matklad]

Would that make insertion text just foo()?

Yes. As I've said, that would be a good initial implementation, which would primarily focus on plumbing the required flags.

For the final implementation, a corresponding flag should be added to the internal CompletionConfig, and than this setting need to be honored everywhere where we use snippets.

After that, we either should assert here that we don't see a compleiton with a snippet, or we should just not add such completions.

[matklad]

After that, we either should assert here that we don't see a compleiton with a snippet, or we should just not add such completions.

I've actually figured a much neater way to do this: introduce an unforgable SnippetCap token, which proves that this capability is available, and add it as an argument to snippet producing functions.

I've implemented this idea in #4116

No the only thing left is the actual plumbing to fetch the cap from the client....

[matklad]

Plumbing implemented in #4117

Here's example of completion with a snippet:

And here's the same completion without the snippet:

[puremourning]

In your example I would still argue that the completion is probably completing too much. It’s unexpected that selecting ‘size’ competes a whole line of text including a function declaration.

I kind of get it. It’s boilerplate, so let’s write it for the user.

My concern is that sort of thing is divisive and opinionated. Perhaps that’s intentional (if so, so be it), but certainly my users are unlikely to expect that and would likely be model-breaking for completion systems and users accustomed to more natural word expansion.

The original point put across by Boris is that completion systems doing too much breach’s workflow because when stuff happens that you don’t expect you end up having to rewind. Let’s say you develop in N languages and N-1 behave one way, eg like clangd or jdt.ls or gopls) and the Nth one behaves like this. The challenge for the user in that case is to switch gears. We would like to avoid having the user switch gears and offer consistent powerful experience across languages.

Anyway just my 2p. Tl:dr there are a large quantity of users that don’t expect the completion system to complete more than a word at a time. It’s probably worth considering that group.