eclipse-lsp4e / eclipse-lsp4e/lsp4e
Support `isPreferred` from `CodeAction`
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 85
- Forks
- 69
- Avg merge
- 8h 33m
- Merged PRs (30d)
- 6
Description
I only have in mind showing a quickfix (marker resolution) created based on CodeAction marked as "preferred" above other quickfixes.
Eclipse sorts quick fixes alphabetically which may not be desirable... For example there are 3 quick fixes proposed to a problem:
- Fix the problem in the current code snippet
- Fix all such problems in the current java file
- Fix all such problems in the corresponding java project
The preferred fix would the current code snippet but it is challenging to push it at the top of the list due to Eclipse's alphabetical sorting. Either label becomes ugly and inconsistent or the order is reversed.
Currently Eclipse sorts the list of quick fixes (together with assists and refactorings) in alphabetical order with org.eclipse.jdt.ui.text.java.CompletionProposalComparator.CompletionProposalComparator. It is not meant to sort alphabetically since the fOrderAlphabetically is false but it falls through to alphabetical order based on resolution labels due to the type of marker resolution object type, i.e. no "relevance" property. The "relevance" property is only available in IJavaCompletionProposal subtypes. However, org.eclipse.lsp4e.operations.codeactions.CodeActionMarkerResolution cannot implement IJavaCompletionProposal because it should be independent from JDT.
What would be your thoughts on this @mickaelistria @rubenporras @angelozerr ?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting org.eclipse.jdt.ui.text.java.CompletionProposalComparator.CompletionProposalComparator and org.eclipse.lsp4e.operations.codeactions.CodeActionMarkerResolution, focusing on how CodeAction preferred status could affect quick-fix ordering. Done means preferred CodeAction-based marker resolutions appear above other quick fixes without making CodeActionMarkerResolution dependent on JDT.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100