-
-
Notifications
You must be signed in to change notification settings - Fork 389
Refactor plugin: Prefer code action #3167
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
Refactor plugin: Prefer code action #3167
Conversation
ddde94c
to
188a602
Compare
When implementing #1235, I did think that the disable-warning actions should probably always be at the bottom of the list, but I couldn't work out how to do that. This looks good! |
@georgefst Cool, maybe we could (in a different PR) also set these code actions to |
Just to confirm, does this work in Vim/Coc? And have you tested with VSCode? |
Honestly, I don't know how all clients behave and I haven't tested in other editors, but I can tell what I know. That being said, the actual effect will likely depend on the client. But these changes add information of what the most reasonable choice of actions is. I think it would also make sense to mark all "disable something" actions as "not preferred", but often seems to need refactoring. Previous ChangeI've tested a similar change in #3018, but this one not again. There are screenshots demonstrating the change in behavior with Vim and CoC. This ChangeTested this change by building it locally. Seems to show "Remove all redundant imports" before "Disable warning". Not sure why the "Remove import" is at the end, maybe they are created in different places. Language Server ProtocolLSP docs say:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/ CoC ImplementationHere is the sorting implementation of coc (vim client). It seems to take the property into account. |
188a602
to
f79310b
Compare
Rebased ✔️ |
`isPreferred` can influence the client side order of code actions. The idea is that an unused import is likely to be removed and less likely the warning will be disabled. Therefore actions to remove a single or all redundant imports should be preferred, so that the client can prioritize them higher. Followup of <haskell#3018>
f79310b
to
b882966
Compare
I actually don't know if clients treat "no isPreferred field" differently from "isPreferred set to false". The LSP spec of course doesn't tell us anything like usual 🙄 This LGTM, we've used this in the past for hlint and I think it's the right thing to do. |
@michaelpj I don't know either. In theory It's a good point though. Adding |
_isPreferred
can influence the client side order of code actions. The idea is that an unused import is likely to be removed and less likely the warning will be disabled. Therefore actions to remove a single or all redundant imports should be preferred, so that the client can prioritize them higher.Followup of #3018
Demo
Here is an example in Vim/CoC. There is an import that isn't necessary. The list of code starts with "Disable unused-imports warnings", which is also the option that would be defaulted to. Instead removing the redundant import should be preferred and will influence the order (depends on the language server client).