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: determine if import organization should be a code action or a save hook #31824

Open
natefinch opened this issue May 3, 2019 · 5 comments

Comments

Projects
None yet
5 participants
@natefinch
Copy link
Contributor

commented May 3, 2019

(this is using the latest VSCode go plugin and the latest gopls)

If I remove a line of code that would trigger an import to be removed, and save immediately, sometimes the import doesn't get removed (same for adding). I noticed that this seems to correspond to whether or not the red squiggle under the import has shown up yet or not.

I wonder if gopls and/or vscode are relying on the results of an asynchronous linter, rather than doing the check during the save, the way goimports-on-save used to work in VSCode.

Anyway, this is a distinct step back in UX, because now if I save "too fast" (which I evidently do a lot) then my imports don't get updated and I have to save again to trigger it.

Feel free to tell me if this is a vscode issue, and I'll go file it there if so.

@gopherbot gopherbot added this to the Unreleased milestone May 3, 2019

@gopherbot gopherbot added the gopls label May 3, 2019

@ianthehat ianthehat self-assigned this May 3, 2019

@ianthehat

This comment has been minimized.

Copy link

commented May 3, 2019

The

    "editor.codeActionsOnSave": {
        "source.organizeImports": true
    },

is basically a temporary hack, while we decide what the correct user interaction really is.
You are correct that fixing imports is related to the squiggles (note that those are not lint errors btw, gopls does not do linting yet, they are type checking errors).
This is because fixing imports is done as a code action associated with the diagnostics that tell it the code is currently incomplete. And yes those diagnostics are asynchronous because we do them as you type and do not want to slow the user down.
We are trying to decide what the best approach is for the user, I generally dislike doing things that might be expensive on save, but if we want to do that we need to move fixing imports to the willSave call. I think in general it will be better to fix imports as you type, but then the question is should it be automatic, or a quick fix activation. Should we fix all imports at once, or just the one for the symbol you activate the fix on.
Input is welcome from anyone that has an opinion on the best possible user interface for managing imports...

@natefinch

This comment has been minimized.

Copy link
Contributor Author

commented May 3, 2019

Well, I mean, basically everyone in the world uses goimports on save right now, so, I guess it's fine, speedwise? Certainly I've been using it forever and it seems fine.

@ianthehat

This comment has been minimized.

Copy link

commented May 3, 2019

There are definitely people for whom it is not fine speed wise. For a file that is fully satisfied it is always very fast, but once you start having to look for new imports it can get ugly. This is especially true for people not using the go tool as their primary build system.
There are some interesting/ugly edge cases where you either have to just give up or take a very long time, neither of which is very palatable (my definition of long time might not match most peoples though)
Also there are also lots of people that do not want to use goimports, they use goreturns and gofmt -s and a bunch of other things, I would like us to be able to allow users to have the union of these tools, not have to pick just one.
I think we are all used to save hooks because they were easy to add, not because they are the best way, and I would like us to take some time to think what the best way truly is. If it turns out that save hooks really are the that way, then we will add the handling to textDocument/willSaveWaitUntil but that message comes with the caveat that if you take to long to calculate the edits it stops waiting for you, which is the right choice for users but will result in exactly the behavior you are currently seeing where if you safe fast enough after and edit and we cannot work out the new import quickly enough it will save without the changes.

@stamblerre

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

Just chiming in to say that the latest version of gopls do not actually wait for diagnostics - they run on save. @natefinch: do you still see this behavior with versions of gopls after https://go-review.googlesource.com/c/tools/+/172406?

@stamblerre

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

Oh sorry, forgot you said you were using the latest versions as of the time you opened the issue. This seems to be just a case of this code action not working fast enough. As @ianthehat said, we are still working on a better approach for this.

@stamblerre stamblerre changed the title x/tools/cmd/gopls: import changes don't work if you save quickly after a change x/tools/cmd/gopls: determine if import organization should be a code action or a save hook Jun 5, 2019

@stamblerre stamblerre changed the title x/tools/cmd/gopls: determine if import organization should be a code action or a save hook x/tools/gopls: determine if import organization should be a code action or a save hook Jul 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.