GeezerVison

We could keep the type annotations in the label (but no the insertText) if we think that makes it more clear or useful, but I think this is probably best.

Yeah, I considered that, but seems rather confusing. But I don't know, given how I didn't even noticed we could do without the type annotations, I could be very wrong.

For really basic signatures I would probably prefer the type annotations displayed; I can see more complex signatures appearing as noise that obscure the parameter names (which would be even worse for JS users).

I can go either way on this to be honest, and hearing from users about it.

Does anyone else find it confusing seeing both bar and bar(x) in the completion list? To me, the way the parameter list is grayed out makes it look like informative context, rather than text that will be inserted.

To me, the way the parameter list is grayed out makes it look like informative context, rather than text that will be inserted.

Could we do something crazy where the type annotations are grayed out and the rest of the text is the usual color? I guess we'd need to return display parts (CC Matt Bierner (@mjbvz))

That sounds cool, but N.B. I don’t think the LSP spec supports display parts: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#completionItemLabelDetails

Does anyone else find it confusing seeing both bar and bar(x) in the completion list? To me, the way the parameter list is grayed out makes it look like informative context, rather than text that will be inserted.

(I was invoked to give my 2 cents here) I completely agree with Andrew's comment. Without any context or previous knowledge of this discussion, I would find it quite confusing as a TS user to see these different entries in my completion list, and I would have no idea of which one is which. Although it would be more verbose and make the list uglier, I would prefer options like:

bar(x)
bar(x: number)

Does anyone else find it confusing seeing both bar and bar(x) in the completion list? To me, the way the parameter list is grayed out makes it look like informative context, rather than text that will be inserted.

(I was invoked to give my 2 cents here) I completely agree with Andrew's comment. Without any context or previous knowledge of this discussion, I would find it quite confusing as a TS user to see these different entries in my completion list, and I would have no idea of which one is which. Although it would be more verbose and make the list uglier, I would prefer options like:

bar(x)
bar(x: number)

Maria Solano (@MariaSolOs) Thanks! One of the things that can be inserted is the bar name (i.e. bar) and the other is a whole method (bar(x) { }). Does that affect how you would like to see them presented?

Does anyone else find it confusing seeing both bar and bar(x) in the completion list? To me, the way the parameter list is grayed out makes it look like informative context, rather than text that will be inserted.

(I was invoked to give my 2 cents here) I completely agree with Andrew's comment. Without any context or previous knowledge of this discussion, I would find it quite confusing as a TS user to see these different entries in my completion list, and I would have no idea of which one is which. Although it would be more verbose and make the list uglier, I would prefer options like:

bar(x)
bar(x: number)

Maria Solano (@MariaSolOs) Thanks! One of the things that can be inserted is the bar name (i.e. bar) and the other is a whole method (bar(x) { }). Does that affect how you would like to see them presented?

Ohhhh now I understand. I thought that the different completion options were both for methods (having types in the method signatures versus not). Now I understand.

In that case I again agree with Andrew Casey (@amcasey) about the different color around the parameter list making it seem like an informative label and not part of the snippet. Personally I would also add the curly braces to better represent the snippet's behavior.