Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: option to autocomplete function call without parentheses #41813

Open
HymanZHAN opened this issue Oct 6, 2020 · 12 comments
Open
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Tools This label describes issues relating to any tools in the x/tools repository.

Comments

@HymanZHAN
Copy link

HymanZHAN commented Oct 6, 2020

(This is more of a question before it becomes a feature request. However, the original Slack invite link is no longer active.)

Is your feature request related to a problem? Please describe.
Is it possible to leave out the parentheses of a method when doing autocompletion? For example, when typing time.No and hit tab, instead of autocompleting with time.Now() is it possible to complete it as time.Now?

Describe the solution you'd like
Have an option for this, something like gopls.includeParenthesesWhenAutocomplete that can be set to false.

Describe alternatives you've considered
N/A

Additional context
I have been writing a mix of C++, Python, and JS/TS, and all these languages' autocompletion on VS Code are without the parentheses. It's muscle memory for me now to reach for ( after completing the method and it's really counter-productive especially when I need to switch between languages.

@hyangah hyangah changed the title Possible to exclude the brackets when doing autocompletion? x/tools/gopls: option to autocomplete function call without parentheses Oct 6, 2020
@hyangah
Copy link
Contributor

hyangah commented Oct 6, 2020

@HymanZHAN thanks for the feature request. This is about adding a new knob for gopls' autocompletion behavior, so I will transfer this to its issue tracker. (cc @stamblerre )

@hyangah hyangah transferred this issue from golang/vscode-go Oct 6, 2020
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Oct 6, 2020
@gopherbot gopherbot added this to the Unreleased milestone Oct 6, 2020
@HymanZHAN
Copy link
Author

@hyangah Thanks!

@stamblerre stamblerre removed this from the Unreleased milestone Oct 6, 2020
@stamblerre stamblerre added FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Oct 6, 2020
@stamblerre stamblerre added this to the gopls/unplanned milestone Oct 21, 2020
@muirdm
Copy link

muirdm commented Nov 21, 2020

If you disable snippets in your editor then you won't get the parens anymore (but will lose other snippet dependent functionality).

Why don't the other languages include parens when completing function calls? I can appreciate not being used to it, but it objectively saves keystrokes.

@HymanZHAN
Copy link
Author

HymanZHAN commented Nov 21, 2020

@muirdm My personal experience actually speaks otherwise. Including parens (and the input inside parens) as snippets does save the keystroke of (. But inside the snippet, you don't have automatic IntelliSense anymore; You have to manually trigger it by Ctrl+Space or you will need to type a lot more. I'd argue it objectively increases keystrokes. This is quite annoying when you have functions with multiple parameters.

Also, it's way easier to mishit Tab and exit the snippet accidentally in the middle of typing, as I tend to hit Tab for autocompletion (even though it's not there). I also use an extension called TabOut, which lets you skip closing characters like " and ). (Old habits from using Visual Studio, without which I will be 10X less productive. 😅) Obviously, using this inside a snippet will exit the snippet first, which is really annoys me.

BTW, my favorite snippet implementation is actually the one of Visual Studio, where you can use Tab to loop through all snippet input space holders, modify previous input, have automatically autocompletion and use Enter to finish the snippet. Sadly that's not how VS Code implements it.😥

@muirdm
Copy link

muirdm commented Nov 21, 2020

inside the snippet, you don't have automatic IntelliSense anymore

I have my editor set up where I do get automatic completions inside the snippet. After inserting a snippet, it automatically triggers a completion at the first placeholder. I can accept it right away (and overwrite the placeholder), or simply start typing to filter completions. I press TAB to choose the inner completion, then TAB again to advance to the next outer placeholder.

I definitely agree that nested completion/snippets is finicky, but I think most of that is just editors not doing it well by default.

@themowski
Copy link

I just encountered this for the first time (long-time non-gopls user who upgraded recently due to modules) and was also surprised that there's no option to turn it off. I don't like autocompletion of anything other than function names in general, and disable bracket completion whenever I have the chance. Like the original reporter, I find that bracket insertion usually increases my keystrokes.

Thanks for the tip about disabling snippet insertion, I will try that as an interim fix and hope that it doesn't break anything else.

@SOF3
Copy link

SOF3 commented May 15, 2023

As a vim user, bracket completion does not help me in any way unless the function has no parameters (in which case it is still inconsistent anyway). Now my standard workflow is to accept the completion and delete the parentheses.

Not sure if it is relevant, but after upgrading to the 0.12 dev version, the parentheses are inserted even when completing a function call that already has parentheses. Not sure if that qualifies for a separate bug.

@hyangah
Copy link
Contributor

hyangah commented May 15, 2023

If you disable snippets in your editor then you won't get the parens anymore (but will lose other snippet dependent functionality).

Disabling snippets completely just to turn off parens in completion isn't ideal. (And it's not something configurable from LSP client at least in vscode microsoft/vscode-languageserver-node#732)

I checked other language plugins and they are either not adding () automatically, or have settings to control behavior around ().

Can we have a gopls setting to disable parens? (For VS Code, there is a separate feature that adds matching ) or }, so not offering parentheses by default is also something to consider)

@muirdm
Copy link

muirdm commented May 17, 2023

It sounds like we need an option. People are used to things, and editors often aren't set up to give an optimized completion experience out of the box. But, I'm still curious about the keystroke level details.

I find that bracket insertion usually increases my keystrokes.

@themowski Can you give an example where it increases keystrokes?

Now my standard workflow is to accept the completion and delete the parentheses.

@SOF3 Are you saying your cursor ends up after the closing paren?

/cc @findleyr

@SOF3
Copy link

SOF3 commented May 17, 2023

@muirdm yes, <c-y>d%. But the main problem is that I sometimes just want to apply the completion to add the import but it generates too much.

In the vim scenario, generating the commas in advance do not help at all because you can't jump to the next argument blank anyway, and the number of parameters doesn't help without knowing the actual argument name/type (which is in the other hover anyway, no need for the pregenerated commas).

@themowski
Copy link

themowski commented May 21, 2023

@themowski Can you give an example where it increases keystrokes?

Sure, when bracket completion is on and a closing bracket is automatically inserted, I usually either:

  1. instinctively delete the inserted bracket (at least one keystroke for Delete, sometimes two for arrow + Backspace); or

  2. keep typing, but then when I type the closing bracket, the one that was auto-inserted often doesn't go away, so I end up having to delete it anyways. I'm not sure what the exact scenario/cause for this case is, it could possibly be because I moved out of the function call, or I stopped to read an argument's docstring, or I auto-completed something else.

  3. Similar to item 2, I often autocomplete a function name, then click somewhere else in the code to modify something else (or perhaps to read a docstring), then come back to the line that I was working on. Because of the auto-inserted closing paren, I need to either click precisely between the parens to pick up where I left off, or I need to click at the end of the line and delete the closing paren. I typically prefer to just leave an open paren only so that I can come back, click anywhere on the right side of the line, and start typing to fill in the arguments immediately.

I'm aware that these items are very specific to my personal coding style, and others may feel that these are non-issues / self-inflicted. That said, I feel like this extension's current behavior is bad UX: the editor is inserting symbols that I did not want/expect to be inserted, given that I have the global "do not insert brackets" option set. When I selected the symbol in the autocomplete menu, I approved the autocomplete of a function name, not the corresponding braces.

However... I don't really have a chance to write Go that often these days, so after playing with it a few times to refresh my memory of what this comment was about, it's less irritating to me now than it was when I commented on this back in 2021.

EDIT: I think the thing that jumped out at me from the original report for this issue was the following:

I have been writing a mix of C++, Python, and JS/TS, and all these languages' autocompletion on VS Code are without the parentheses. It's muscle memory for me now to reach for ( after completing the method and it's really counter-productive especially when I need to switch between languages.

This is 100% valid and, after testing it out really quick just now, I am certain that this is what really was annoying to me about this behavior. Like OP, I tend to write in multiple languages, and what I'm doing on a given day depends on the project I'm working, and when the editor's behavior is inconsistent between languages, it's really hard on muscle memory.

@SOF3
Copy link

SOF3 commented May 22, 2023

I think a bare minimum is that commas should not be completed. There is no point in inserting commas at all; the user has to type it either way to get function signature hint, and moving cursor to right is barely better (if not worse) than typing the comma manually. Commas are worse than closing parentheses because most editors just move rightwards when you type in front of an existing ), but insert a duplicate comma when you type in front of an existing ,, and commas do not have any of the grouping impacts like () does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

7 participants