Community
Participate
Working Groups
Scenario: - Object "box" has a field "h" with method "get()" - I want to type "box.h.get();" - After typing "box.h", autocomplete shows a list, including "hashCode()" and "h". - I type "." after "box.h", and autocomplete fills in "box.hashCode()." rather than leaving it as "box.h." What should happen is that when a non-alphanum char is typed, the autocomplete list should be checked for a perfect match (here "h"), and should use that instead of the first thing in the list. 3.1RC1.
works for me using 3.1 RC3.
This is still broken on 3.1 final.
Works for me using R3.1. Maybe some more detailed steps would help to show the problem?
Really the same problem as bug 97430 - trigger characters insert the selected proposal, even though the typed in text exactly matches a different proposal.
(In reply to comment #4) > Really the same problem as bug 97430 Wrong - a similar problem is in bug 98064.
what is the ordering in your proposal popup? Is 'h' before or after 'hashCode'?
Daniel, I don't know why you resolved this as RESOLVED WORKSFORME, since I said that I re-tested it and it is still a problem in 3.1 final, i.e. R3.1, so it is not actually fixed in 3.1 yet. I guess I just didn't give enough detail to duplicate the problem. I think this can be timing-related -- you may have to wait for the autocomplete box to pop up. I haven't nailed it on the head yet. It's also not always a problem I think, but I'm not sure. I have another example of where it has been a problem: I have two fields in a class, parent and parentDX. Typing "obj.parent." quickly gives "obj.parentDX." immediately. Deleting back to "obj.parent" then typing "." quickly seems to eliminate the problem occasionally, but if I wait for the autocomplete dialog to pop up, it always still inserts the "DX". The item that is filled in is always the top item in the list, i.e. "hashCode()" is always above "h" in the popup, for the initial example.
>Daniel, I don't know why you resolved this as RESOLVED WORKSFORME, Because going through your scenario works for me. > I guess I just didn't give enough detail to duplicate the problem. Correct. OK, from what you tell me now and together with the additional example you're seeing bug 98064. The interesting question is why 'hashCode' is before 'h' in your workspace. This is not the case in my workspace no matter how I sort the proposal list. Would you mind to attach the code and your settings?
Ah, I figured it out. this.h.get() returns a float. If I type this.h|.get(); then at the caret position "|" I see "h" at the top of the list. If I type float currHeight = this.h|.get(); and I type it too slowly, then I see hashCode() at the top of the list. The problem is that autocompletion looks and sees that the Lvalue is a numeric type, and hashCode() returns a numeric type (int) that can be implicitly casted to float. h is of type ValueAnimator which itself is not a numeric type, so if the Lvalue is "float currHeight" instead of void (as in the first example above), then it selects hashCode() in preference to h. I have noticed before that the sort order sometimes changed on me for no reason I could really discern -- until I noticed that autocompletion is looking at the Lvalue type for clues as to what to move to the top of the list. This is probably almost always the right thing to do, so I'm not suggesting it should be changed. The real problem is that if I type something that is completely contained in the autocompletion list, and then I type a period, then autocompletion should not choose the item at the top of the list. Alternatively, if there is a symbol that is exactly equal to the autocomplete text, it should be shown at the top of the list, so that when the period is pressed, it is selected. This is just a special case of the current behavior. The programmer should be able to type a full reference path without having autocomplete interfere with what ends up being added to the editor.
That explains hashCode() being on top. 1) Imagine you're a different user but same scenario and you wanted to insert hashCode(): since hashCode() is the first in the list, you press '.' and get "h. Your next step would be to file a bug report ;-) 2) What would be selected using your approach if the proposal list contains: 'h' 'hh' or 'hh' 'h' I guess if we implement this we have to pre-select the proposal that would be inserted instead of the first one. However, I think this smartness would confuse users more than the current behavior. Tom, what's your take on this?
The smartness of lvalue checking already confused me. I couldn't figure out why the list sort order was sometimes different -- it was because sometimes I was able to ignore the lvalue successfully, on method calls which had side effects. I have observed this multiple times, not just on the h/hashCode example. The solution to "1)" is to read the user's mind. Why has this not yet been implemented? ;) On the subject of "h"/"hh", the current list correctly sorts the shortest matching prefix to the top *unless* the lvalue override comes into account. I say this is the "correct" thing to do, because if hashCode() didn't exist, then pressing "h." would actually give the intended (in this case) choice, because if the entered text before the period is pressed is exactly equal to an item in the list, that item will be the top completion, because it is the shortest matching string with the entered text as a prefix. The only difference I suggest to the current behavior is that, as I mentioned in my previous comment, all items in the autocomplete list that exactly match the text that has been entered so far should be moved to the top of the list. If there is more than one perfect match, then regular sort rules should apply within that list of exact matches. Other than that, for all other items in the list (or all items in the list, if there are no perfect matches), the current autocomplete list is in about the best order it could be in, given the subjectivity of the problem (as you point out well in "1)" -- I actually need hashCode() myself occasionally :) ).
IMO we should keep the sort order stable, so changing the relevance of a proposal as you type is not a good idea. Selecting a 'perfect match' may make sense - we should investigate how that feels.
Or we could add an option to disable auto-selection triggers i.e. '.', ')',;',... would simply dismiss code assist instead of selecting a proposal. Luke, would you enable such an option?
Very possibly. I discovered that the autocomplete time delay was configurable after filing this bug, which achieves a similar thing. However right now the main way I select an autocompletion is by pressing Enter (suboptimal in terms of number of keystrokes, I know, but I got in that habit somehow because it seemed intuitive to me to make a choice using Enter). It is possible that you could disable ., ; etc. if a choice is not selected in the autocomplete box. In conjunction with that you could also make it so that the first choice in the autocomplete box is not selected by default, so the user has to press the down arrow to select the first choice. Once selected, . etc. would autocomplete. The heart of the issue though is more what I explained in previous comments -- this is mainly a problem when you are trying to type the whole object reference path by hand ("obj.h.get()"), and when one element of that ("h") is a proper prefix of a higher-precedence autocompletion ("hashCode()") at that point. In other words, I'd be happy with the current autocompletion system with no changes other than the following: if the "Insert common prefixes automatically" option were hypothetically chosen, and it would insert a common prefix based on the current token as far as entered, and that prefix itself is a complete standalone symbol in the autocompletion list, then autocomplete with '.' etc. should be disabled if that prefix is not the first item in the autocomplete list, whether or not "Insert common prefixes automatically" is enabled. That way you can type complete symbols that are not the highest autocomplete option on the list without autocomplete putting wrong completions in when you hit '.'. I don't know if I'm explaining this very well. Does this make sense? Thanks..
>you could also make it so that >the first choice in the autocomplete box is not selected by default That we(I) do not want ;-) We would offer such an option as preference. Adding it in some situations behind the back would even introduce more confusion. Having said that, I sill like the idea of selecting the perfect match while typing. This would also solve your issue.
If you are talking about having just one exception in the sort ordering, which is to always move the perfect match to the top of the list if there is a perfect match present (and below that point in the sort order, and in all other cases where there is no perfect match, the sort order stays the same as it is now), then that would certainly solve my problem.
>always move the perfect match to the top of the No. See comment 12.
I see, I forgot about comment #12. I like Tom's suggestion in the second part of comment #12 then, selecting the perfect match even if it's not at the top of the list.
