Hlint: CodeAction with isPreferred #3018
Conversation
|
Please include the rationale for why we're making this decision as a comment in the code. I think your argument is good, and probably extends to other code actions that are produced directly from diagnostics. The "add pragma" code action seems like another good candidate. I'm not totally sure what our rubric should be, though. Arguably ignoring the hint also clearly deals with the diagnostic, maybe both should be preferred? I don't know. I think it's reasonable to assume that if people have the hint enabled globally they probably want to fix it rather than ignore it. |
Sure thing 2a9a687
That would also be my main argument. I know the project needs to work for different projects and developers, but the main influence of |
> A refactoring should be marked preferred if it is the most reasonable choice of actions to take. For hlint it is the likeliest choice to apply the fix. Ignore the rule for the complete module is preferred less.
Including the rationale for why we're making this decision as a comment in the code.
andys8
force-pushed
the
improvement/hlint-codeaction-is-preferred
branch
from
2a9a687 to
ab7f57b
Compare
* Hlint: CodeAction with isPreferred > A refactoring should be marked preferred if it is the most reasonable choice of actions to take. For hlint it is the likeliest choice to apply the fix. Ignore the rule for the complete module is preferred less. * Hlint: Comment for isPreferred Including the rationale for why we're making this decision as a comment in the code.
`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 prefered, so that the client can prioritize them higher. Followup of <haskell#3018>
`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>
`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>
`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>
`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>
`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>
For hlint it is the likeliest choice to apply the fix. Ignore the rule
for the complete module is preferred less.
Related to #2057
Demo
The client - in my case Vim/Coc - can respect
isPreferred. In case of CoC it will be reflected in the sort order of code actions.Before
After