Community
Participate
Working Groups
Created attachment 247693 [details] "class" being suggested before exact match "C" I have a fairly complex tree of interfaces used to contain various constants. Two of the nested interfaces are named "C" and "Java". When attempting to type the name of anything in one of these nested interfaces, e.g. "XCSG.C.StaticLocalVariable", the autocomplete will automatically convert the "C" to "Java". This is because the autocomplete after typing "XCSG.C" considers "Java" to be the best match. "C" appears dead last, after "Java" (which doesn't match at all), and after all of the fields that start with "C". I have screen shots for this, but am not attaching them because of the one attachment limit. I haven't been able to reproduce this exact behavior in a minimal example, but I am also attaching a screenshot of a minimal example with a related problem: in this example, typing "Bar.C.foo" results in the text "Bar.class.foo", because the inexact match is preferred over the exact match. Version: Kepler Service Release 2 Build id: 20140224-0627
(In reply to Theodore Murdock from comment #0) > Created attachment 247693 [details] > I haven't been able to reproduce this exact behavior in a minimal example, > but I am also attaching a screenshot of a minimal example with a related > problem: in this example, typing "Bar.C.foo" results in the text > "Bar.class.foo", because the inexact match is preferred over the exact > match. In this case, the problem is only about the priority given to suggestions, right? If I understand it right, your main concern is that auto complete picks something that you didn't select? Is that correct? If so, that looks like a bigger problem.
My impression is that Eclipse picks something that I didn't select because "." is one of the keys that automatically picks something without requiring you to use arrow keys, similar to hitting "return". Having "." be an autocomplete trigger is convenient in cases where Eclipse is suggesting the right thing, so if I need to type "bard.bazooka.foo" I can actually type "bard.baz.foo", and have the Eclipse autocompletion add in the "ooka" for me. What I'm not fine with is that this behavior sometimes replaces something I typed correctly with something I didn't intend to type at all. That erroneous behavior would go away if Eclipse were getting the ordering of the suggestions correct, with an exact match to what you have already typed coming first instead of last. That or, if the "exact match should be the last suggestion" rule is to be kept, there also needs to be a rule that you must select something with the arrow keys or mouse before Eclipse is allowed to replace something, if what you typed already perfectly matches a field or member type.
It also occurs to me that the bug might just suggest that there's some general bugginess with type suggestions in Content Assist. The fact that it sometimes suggests "Java" (another interface) as a possible completion for "C" is what leads me to this conclusion. Even if Types are not considered as possible proposals for autocompletion, it's important that they not be autoreplaced when correctly typed, just because there happens to be a field whose name starts with the same letter(s).
(In reply to Theodore Murdock from comment #0) > Created attachment 247693 [details] > I haven't been able to reproduce this exact behavior in a minimal example, > but I am also attaching a screenshot of a minimal example with a related > problem: in this example, typing "Bar.C.foo" results in the text > "Bar.class.foo", because the inexact match is preferred over the exact > match. This is what I see: When you have typed Bar.C and invoke content assist, you go get the C ahead of class. But if you invoke content assist first and type "C", the orders don't change. That's the expected behavior. I tested this in the latest 4.5 build. You can try attaching the other examples you cited in comment #0, as source code if possible, so I can take a good look at the problem.
(In reply to Jayaprakash Arthanareeswaran from comment #4) > This is what I see: When you have typed Bar.C and invoke content assist, you > go get the C ahead of class. But if you invoke content assist first and type > "C", the orders don't change. That's the expected behavior. That is *not* the expected behavior in this case. Just typing "." invokes Content Assist, the fact that having "." as a Content Assist trigger automatically replaces correctly typed code with incorrect code is a serious flaw, not "expected behavior". Clearly the list of items provided by Content Assist changes when I type "C" after typing the ".". Why then should the ordering be different based on whether I invoked Content Assist before typing the "C" or after? Even if there is some justification for wanting stability in the ordering of suggestions, that requirement certainly shouldn't be carried to the extreme of saying it's more desirable to avoid re-ordering than to avoid substitution of correctly typed code with incorrect code. At least in the case of an exact match, the exact match must be moved to the top of the list to prevent this bug.
I've come across this bug quite frequently, and most annoyingly with the standard java.util collections classes. For example, if I begin (using a java.util.List) with 'list.add(' - the . begin auto-complete, and the ( automatically selects the top result, which is 'addAll' as frequently as it is 'add'. This is extremely counterintuitive, and hurts productivity - I now have to carefully check even the things I know I typed correctly.
(In reply to Logan Pickup from comment #6) > I've come across this bug quite frequently, and most annoyingly with the > standard java.util collections classes. For example, if I begin (using a > java.util.List) with 'list.add(' - the . begin auto-complete, and the ( > automatically selects the top result, which is 'addAll' as frequently as it > is 'add'. This is extremely counterintuitive, and hurts productivity - I now > have to carefully check even the things I know I typed correctly. > I've come across this bug quite frequently, and most annoyingly with the > standard java.util collections classes. For example, if I begin (using a > java.util.List) with 'list.add(' - the . begin auto-complete, and the ( > automatically selects the top result, which is 'addAll' as frequently as it > is 'add'. This is extremely counterintuitive, and hurts productivity - I now > have to carefully check even the things I know I typed correctly. Are you on Kepler or earlier? I had this issue all the time with Kepler, but since switching to Luna it's been working fine for me. Haven't tried Mars yet, so I can't say whether it's reappeared there. Then again, I'm not certain that the fact I'm not seeing this issue means the issue is not present for Luna...I think Eclipse can also do things to predict what you're going to type, so it may depend on usage patterns. It's possible I'd been typing .class a lot, and this caused Eclipse to expect me to type .class, resulting in giving it higher priority in the list, and then in the replacing of .C. with .class. (The bug may even be self-reinforcing if it counts times that you took its suggestion as times that you deliberately typed something, and does not detect from your correction that it was a dramatic failure that the auto-complete feature should be ashamed of having suggested.) I suppose the way to test whether it's still present would be to ensure "." is set as an autocomplete trigger, use List.addAll() a lot, until it's ranked higher than List.add() in the autocomplete suggestions (if longer matching strings cannot be listed before shorter ones, this bug cannot happen...in my case I suspected the inversion was because Types were given very low priority, while fields were given very high priority, in Logan's case it may be due to usage patterns as perceived by Eclipse), and then try typing "List l; l.add(", to see whether Eclipse auto-inserts "All" in the middle.
> > Are you on Kepler or earlier? I had this issue all the time with Kepler, but > since switching to Luna it's been working fine for me. Haven't tried Mars > yet, so I can't say whether it's reappeared there. I've been using Luna for quite a while, and that's the only environment I noticed the problem in. Never noticed it on Kepler. I just downloaded Mars and imported the same set of projects, and the issue does not exist; even when re-using the old Luna workspaces. Not sure how addAll() became higher-ranked than add() - I use the latter more often. Perhaps it artificially became higher-ranked due to its own suggestions causing me to mis-type more often, perhaps after typing one or two addAll() calls early on in the installation? Whatever the cause, the simplest solution for me is definitely to switch to the new Mars installation.
I am not content assist expert, but will take a look later during 4.6. Meanwhile if someone can find time to provide a fix, I could look at it.
No progress yet and unlikely to get time during 4.6. Moving out.
The following may be a variant of this issue: I have a field and a method: MethodBinding clone; boolean isClone(MethodBinding binding) { ... } I'm trying to access the field by starting to type this: if (this.clone != null) At the point where I type the space after "clone" completion changes this into if (this.isClone(binding) not nice
Bulk move out of 4.8
I noticed the same problem with Eclipse 4.12 on MacOS Mojave (10.14.6). How to reproduce:: public class Context { String path; String newPath; public Context() { this.path //autocompletes incorrectly to 'newPath' when typing '=' } } Note that if instead of pressing '=', I just change the focus, then go back to the 'this.path' line, press Ctrl+Space to trigger the autocomplete suggestions then 'path', which is the expected behaviour.
If you set "Disable insertion triggers except enter", then it wont do this
Just for the record, whenever there isn't a major bug that really breaks the functionality of Eclipse, I'm convinced this bug is easily the most annoying thing about developing Java in Eclipse. I've never mentioned this bug to any developer who's worked on Java in Eclipse for any length of time without them saying "Oh yeah, that's happened to me too, and it really pissed me off." I don't think turning off other autocomplete triggers is a viable alternative, because '.' is so useful as an autocomplete trigger, there just needs to be a quick double-check for an exact match inserted into the process, or the list needs to re-order itself by moving any exact match for what's been typed so far to the top of the list (which would solve the issue without needing to double-check for an exact match post-autocomplete-trigger).
What to users seems like a single bug was probably a cluster of different root causes with similar effect. I remember the following having a finger in the pie * sub word proposals * Code Recommenders * Mylyn I know that some of these have been fixed, and Code Recommenders is no longer relevant. To identify if there's any use case still showing the same old annoying problem it would be good to know: * did you use the latest version of Eclipse (if not: which exactly) * did you have Mylyn installed? * tasked focused proposals enabled?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
