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: Postfix complete supports ordinary functions #64799

Open
rogeryk opened this issue Dec 19, 2023 · 5 comments
Open

x/tools/gopls: Postfix complete supports ordinary functions #64799

rogeryk opened this issue Dec 19, 2023 · 5 comments
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@rogeryk
Copy link

rogeryk commented Dec 19, 2023

gopls version

14.2

go env

unimportant

What did you do?

unimportant

What did you expect to see?

Now gopls already support postfix complete, which is very useful in some scenarios, but these all provides pre-defined.
Some completion is just some ordinary functions.

  • for string:split, join
  • for slice: len, append

In fact, we do not need to pre-define these functions, just need to search for all the first parameter types according to the type of X in X.Sel, and then match the name of Sel.
For example, the following program s, all functions in strings should appear in completion.

var s string
s.|    // complete: HasSuffix, Split, ContainsRune, ...

This feature is useful for some basic types, such as string, slice, map. There are also places to pack different implement using functions, such as Context.Context types.

For some types, these completions may cause disturb, so it should have a relatively low priority.

What did you see instead?

unimportant

Editor and settings

No response

Logs

No response

@rogeryk rogeryk added gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. labels Dec 19, 2023
@gopherbot gopherbot added this to the Unreleased milestone Dec 19, 2023
@suzmue suzmue modified the milestones: Unreleased, gopls/backlog Dec 19, 2023
@muirdm
Copy link

muirdm commented Dec 20, 2023

Interesting idea. This might make more sense outside postfix snippets since it involves searching for matching candidates. It's also a less-bounded search than the normal search of object methods, so we would probably have to limit the search scope somehow.

@findleyr
Copy link
Contributor

findleyr commented Jan 9, 2024

Interesting. Whenever I want to use something from the strings package, I start by typing strings.. Why is it desirable to start with the argument and complete "backwards"?

@rogeryk
Copy link
Author

rogeryk commented Jan 10, 2024

Let me explain in detail why:

  • First of all it is a style, I think some functions should be treated as methods, cause some built-in types or types in other packages cannot add methods. So it makes sense to complete them like methods. In c#, kotlin, swift, they have "extension function" to solve this.
  • It will allow you to type less and have a better experience. If you forward input, you need to type "pkgName", "funcName", "varName". In backward complete, you need to "varName", "funcName". And it doesn't go against your intuition, as mentioned earlier, some functions should be treated as methods.
  • And It's not just a matter of hitting a few keys. In many projects I work on there are many packages like "strutil", "timeutil", "sliceutil", sometimes you can't be sure which package a function is in.
  • Postfix completion has some additional advantages when modifying code, for example. Like the code below, the return of someFunction is a string. Now I wish to remove the spaces on both sides (strings.TrimSpace),I had to move the cursor to the front, type, and then move the cursor to the back to complete the brackets. But in postfix completion, you just have to keep the cursor behind and complete.
a := someFunction()

@findleyr
Copy link
Contributor

@rogeryk thanks for the explanation. It's an interesting idea, but definitely not trivial, and I'm not sure it is worth it. We will reconsider when we cross-prioritize feature requests.

@rogeryk
Copy link
Author

rogeryk commented Jan 22, 2024

@findleyr From a comparison of the difficulty of implementation and the benefits, it does seem a bit mismatched. The main reason for this idea is that I feel after implementation, users will no longer need to customize suffixes. Currently, there is no support for users to customize suffix completion. Are there any plans for this?

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. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

5 participants