Thank you for filing a gopls issue! Please take a look at the Troubleshooting section of the gopls Wiki page, and make sure that you have provided all of the relevant information here.

Not related, but I think it's a bit funny to have gopherbot yell at me for submitting an issue using gopls bug. 😄

Thanks for reporting. Filed #34042 for the GopherBot issue.

/cc @muirrn

Edit: Sorry, wrong Muir again!

There is definitely something to improve here, but I'm not sure changing it to never overwrite the postfix is the solution.

In general we can't be sure if your intent is to prepend something new or to replace entirely. In your example, you might instead want to replace t.DoSomething() with t.LeftyRighty(), in which case the current behavior of replacing the entire identifier is what you want.

It also would be a bit weird for gopls to leave an invalid identifier after performing a completion (e.g. leaving t.LeftDoSomething() per your expected behavior). Note that it currently leaves t.Left() which is also invalid.

On master, deep completions give you another option. In your example, I get a completion candidate for Left.DoSomething, which when selected results in t.Left.DoSomething().

A maybe good idea is to augment the deep completion matching to take into account the postfix. In your example t.L<>DoSomething() the prefix "L" matches "Left", but we could see the postfix "DoSomething" matches really well to "Left.DoSomething", so we present the deep candidate "Left.DoSomething" ranked above the non-deep candidate "Left". I feel like this approach is pretty flexible and could let people do something cool things once they get a feel for how it works.

One other workaround is to insert an extra "." (or space) before completing, i.e. t.L<>.DoSomething().

Personally, I don't find leaving invalid code after a completion "wrong", at least not in the course of editing. Every editor/IDE I've used has the same behavior, where a completion will insert what you asked it to, then you're left to finish it off (including Go completion, pre-gopls). Overwriting the whole token to the right is unexpected and I spend more time trying to undo things than the benefit I might get when it does the right thing. I get that gopls itself has no idea what the intent is when a user types something, but my guess says that deleting code is usually not what the user wants to do when accepting a completion (and LSP initially only supporting insertText with TextEdit later is an indicator).

Deep completions are something I've never seen until gopls (and they're interesting, if not sometimes offputting; I've been using master for a while now), but I feel like using them as the solution to this problem is not entirely correct, since there are cases where there wouldn't be a match. I constructed this case to be short enough to show the overwrite, but it doesn't really represent a piece of code I've ever written.

Inserting an extra . is certainly a workaround that prevents the issue. I'll see if I can remember to make a note the next time this happens to me to show it in a non-constructed light.

At the least, it'd be nice to have an option to force gopls to use insert-only edits, just to have it match everything else my editor is doing and not trip me up all the time...

Every editor/IDE I've used has the same behavior, where a completion will insert what you asked it to

We may very well end up just going with this behavior, but I'd like see if there is a smarter approach that does what the user wants and saves time/keystrokes vs the status quo.

using [deep completions] ... is not entirely correct, since there are cases where there wouldn't be a match

Can you give an example where you don't want to overwrite but the postfix doesn't match a deep completion?

Deep completions are .. sometimes offputting

Can you elaborate on this? I'm very interested in feedback regarding deep completions.

Can you give an example where you don't want to overwrite but the postfix doesn't match a deep completion?

The most obvious case is when there's a method call in the middle. The example I gave really only works because it's a single extra thing and is a member access. I'd have to go looking for a better example, as I wrote down this bug to report (and then waited a bit too long before sending it in...)

Can you elaborate on this? I'm very interested in feedback regarding deep completions.

I'd have to sit down and code and see if I can produce any specific examples, but my main issue has been that they've almost never been what I wanted, and seemed to appear at the top in some cases.

An odd case I can come up with from playing around is when you're just starting to type the package name, and it's suggesting stuff inside the package before you've finished it at random. For example, if I start to type opentracing, I'll get a completion item for opentracing the package, but then 3 random members of opentracing that change depending on the number of characters of opentracing I've finished typing... It's weird.

Another thing is that it seems like gopls will try to pick the "best" completion item based on an expected type, so the deep completions will often show up first, even though I'm much less likely to want to access something that's a deep completion away.

The most obvious case is when there's a method call in the middle

Not sure I understand, exactly. Hopefully you come across a good example you can share.

if I start to type opentracing, I'll get a completion item for opentracing the package, but then 3 random members of opentracing that change depending on the number of characters of opentracing I've finished typing

It is true that the deep completions in that case are a bit arbitrary, but it is convenient if, for example, you are trying to call opentracing.DoSomething() you can probably just type "DoSo" or "otds" or maybe just "ds" and complete straight to what you want. If you don't know what you want, "opentracing" the package is still the first candidate, like you said. But, it sounds like the deep candidates are still distracting to some degree. We can probably do a better job filtering out low quality candidates.

gopls will try to pick the "best" completion item based on an expected type, so the deep completions will often show up first, even though I'm much less likely to want to access something that's a deep completion away.

Deep candidates will always be ranked below non-deep candidates, so if deep candidates show up first it means either there are no non-deep candidates that match the type, or your search prefix matches the deep candidates much better than the non-deep candidates. Do you have an example where a deep candidate you did not want was ranked higher than a non-deep candidate you did want?

The general goal is deep candidates never get in your way and often save a lot of typing. If you have examples where they slowed you down I'd love to see so I can improve things.

Change https://golang.org/cl/196119 mentions this issue: internal/lsp: don't overwrite suffix when completion prefix empty

@muirrn Forgive me for not commenting on gerrit (haven't used it yet), but wouldn't that CL not fix this issue per se? It says that it only works if the prefix is empty, which to me seems like will never be the case in normal usage, as presumably one would want to type a few characters to select the right completion rather than using no prefix and arrowing through until the right selection is found. I get that it's a middle ground, but it's not exactly what I thought would happen.

Forgive me for not giving more feedback; I've been busy and haven't had any interesting thoughts about deep completion to share.

Yes, you are right of course. Let me try again later.