x/tools/gopls: consider using &S form instead of *S for pointer type struct field autocompletion

[hyangah]

Currently autocompletion for a struct field uses the field's type as the placeholder text. For example,

type F struct {...}
type S struct {
   Field *F
}

The autocompletion for the Field will return "newText":"Field: ${1:*F},".
gopls uses the type info for placeholder text, so I don't think the choice is incorrect nor invalid.

But if the suggestion used &F instead, it would be more convenient when users want to use composite literals. Especially, if the type name is long to type, reusing what's already in the placeholder will save many keystrokes.

(Based on golang/vscode-go#85)

[stamblerre]

/cc @muirdm

[muirdm]

This was discussed briefly in #38416, but we should consider getting rid of the struct field placeholder text altogether. It is weird to insert invalid, informational Go code when most editors already present the type information to the user.

Composite literals prepend the "&" for you automatically as needed, and sometimes you don't want a composite literal, so I don't think having "&" placeholder text is a net win.

[hyangah]

@muirdm Interestingly I found the struct field placeholder is useful when dealing with badly named long type names with common prefixes, even though I dislike the current way of formulating function parameter place holders.

I don't know about other editors, but at least, in VS Code the suggested text syntax is followed. So if I don't want a composite literal, just typing the other value at the cursor completely replaces the entire suggested text with my input. Actually, that's easier than using the suggested text.

VS Code presents the type info as a hover message, which means I have to hover over the field to remember the type name to trigger meaningful autocompletion results. Additional cognitive overhead. It would be convenient if &someproto.VeryLongMessage{} was suggested. (And, syntax-wise, it's a valid syntax)

As a workaround, I hoped just typing & triggered completion and suggested the suitable composite literal snippet for the field, but it doesn't seem like VS Code ever triggers autocompletion with this symbol (&) for a reason I don't know. :-(

BTW I didn't encounter automatically prepended "&". Is there any configuration I need to set to enable it? Or, do you mean the fact that the completion response includes &F{} as one of the candidates?

[muirdm]

It would be convenient if &someproto.VeryLongMessage{} was suggested.

Yes, that would be convenient in many cases. And of course it also contains the type information of the current placeholder.

As a workaround, I hoped just typing & triggered completion

You can also try triggering completion without typing anything at all (ctrl-space in VSCode I think). That will often pop up the literal candidate. I think you can use ctrl-space to trigger completion after "&" as well. Perhaps you can configure VSCode's "trigger" characters to include "&".

I didn't encounter automatically prepended "&" ... do you mean the fact that the completion response includes &F{}

Yes, the candidate will include "&" if it needs to be a pointer. In your example you could type "Very" and probably get a candidate for "&someproto.VeryLongMessage{}".

@stamblerre how do you complete a long composite literal for a struct field value when you don't remember the name? Do you rely on hover popup, trigger completion manually, or something else?

[stamblerre]

@stamblerre how do you complete a long composite literal for a struct field value when you don't remember the name? Do you rely on hover popup, trigger completion manually, or something else?

Ah, so I was confused by this and now I see why this has never been an issue for me. I don't use placeholders, so when I complete a struct literal, it looks like this:

(This image shows a completion triggered at Field: <> inside of the S struct literal, with the first option being &F{}.)

I also trigger completion manually a lot with Ctrl + Space. This flow works well for me, but I could see it being hard with placeholders. I would support having the placeholder be an &veryLongName{<>} with the <> marking where the user's cursor ends up. I'll turn on placeholders for a few weeks to learn more, and obviously I defer to the opinions of anyone who does use placeholders.