Community
Participate
Working Groups
Created attachment 283285 [details] Subword matching content assist bug Below is a example: Class java.nio.file.Files has three methods whose names contain `exists`: exists(Path path, LinkOption... options) deleteIfExists(Path path) notExists(Path path, LinkOption... options) I typed the `Files.exist` in Java Editor and pressed `Alt+/` to trigger content assist, the letter `e` was changed to `E`, and there are three suggestions in popup dialog: exists(Path path, LinkOption... options) deleteIfExists(Path path) notExists(Path path, LinkOption... options) After I chose the first suggestion, the third suggestion was inserted into the editor.This is not what I expected.
The upper case Exist originates from JFace's common prefix completion. Given the proposals "notExists", "exists" and "deleteIfExists" (in that order), it computes the common prefix "Exists" for mixed proposals. If the order were [exists, notExists, deleteIfExists], it would compute a lower case "exists" prefix. That doesn't matter for case-insensitive substring matches, but does for subword matches. Noopur & Dani: any ideas? I'm hesitant to introduce more JDT-specific handling in JFace. One idea would be, given two compatible prefixes (CompletionProposalPopup::isPrefixCompatible), to pick the more lower case one of both. But I'm not certain that would cover all cases.
I tested code completion with this example in VS Code, it was Okay. So I wonder why Eclipse IDE has this bug.
I find the reason why this happens: I enable `Insert common prefixes automatically` via `Preference > Java > Editor > Content Assist`. You can enable this feature to reproduce the bug.
Even if "Exists" is computed as the common prefix (which should be fixed to not change the case that is inserted by the user if an exact match of that case is found in the list), why the third proposal is being inserted even though the user explicitly selected the first one from the list?
(In reply to Noopur Gupta from comment #4) > Even if "Exists" is computed as the common prefix (which should be fixed to > not change the case that is inserted by the user if an exact match of that > case is found in the list), why the third proposal is being inserted even > though the user explicitly selected the first one from the list? Good point! It seems like a bug in async content assist (I can't reproduce it without). When the proposal is selected, the displayed proposal order doesn't match the fFilteredProposals list. The field is written three times: 1) computeAndPopulateProposals callback (with unsorted proposals - notExists comes first) 2) setProposals called by the callback (now sorted by relevance) 3) AsyncCompletionProposalPopup::incrementalComplete - again unsorted The last write seems wrong here (or should sort afterwards?) - adding Mickael. In any case, this is not a bug in JDT.
(In reply to Julian Honnen from comment #5) > 3) AsyncCompletionProposalPopup::incrementalComplete - again unsorted > > The last write seems wrong here (or should sort afterwards?) Your analysis seems correct. I think it would be relatively easy to write a test case (independent of JDT) for that using the Generic Editor test suite. Then deciding when to sort becomes an implemnetation detail ;)
FWIW, all my current development time is totally consumed by other stuff (Tycho) and I won't be able to code a patch for it before mid-July. However, I'd review patches from others with high priority.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/165670
*** Bug 564700 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/165670 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=346438a6b7596c7ca692bfa7bb248233d5db2372
Thank you everyone.
Hello, I test the issue with the latest Eclipse IDE(Build id: I20200707-0600). I think it is better not covert the first letter to uppercase(In this case, not to convert `e` to `E`).
(In reply to Gao Hao from comment #12) > Hello, I test the issue with the latest Eclipse IDE(Build id: > I20200707-0600). > > I think it is better not covert the first letter to uppercase(In this case, > not to convert `e` to `E`). I opened bug 565037 for that part of the issue. Verified that the selected proposal is inserted with I20200706-2300.
*** Bug 567025 has been marked as a duplicate of this bug. ***
