Community
Participate
Working Groups
Code assist closes when the list would filter to 0 items. This means, for example, that mistyping a method name will close code assist forcing you to reopen it after backspacing over the incorrect character. A better approach would be to jump to the entries in the list as you type instead of filtering the list. This would have the following advantages: 1) Mistyping does not close code assist. Simply backspace and type the correct charater and code assist will continue to follow. 2) If you begin typing something (a method name for example) then realize that you don't remember the name of what you are looking for, you can just scroll through the list. Currently, you have to completely backspace over what you typed (to restore all filtered items) and then scroll through the list. 3) Should also be faster as eclipse does not have to keep regenerating the list -- it only has to select the first item that matches what you have typed so far. This is how Visual Studio 6 implements code assist, which I have found to be very useful and unobtrusive.
I just discovered that tab sets focus to the code assist window, allowing you to type to jump to an item without causing the list to filter or go away. However, this suffers from the following problems: 1) You have to press tab to set focus to the list before typing the item you are looking for. The goal of code assist is to save keystrokes, which this does not do. 2) You can't Shift+Tab back out of the list. This means that if you want to get your caret back and have code assist open, you have to press Esc to close code assist (to get your caret back) then reopen code assist. 3) You have no feedback as you type. 4) If you mistype, you either have to stop typing for a moment or hit an arrow key (so it will start searching from the beginning of the words again), then retype from the beginning. This would not be an issue if the code assist window simply tracked what you typed, as you could just backspace over the incorrect character and continue typing.
we will not change this for 2.0. Both approaches (filtering, selecting) are useful. We could consider surfacing a preference after 2.0
What's about simply not closing code assist if the list filters to o items ?
Reopening for 2.1 consideration
*** Bug 82440 has been marked as a duplicate of this bug. ***
*** Bug 277037 has been marked as a duplicate of this bug. ***
I just unknowningly opened a dupe of this (bug 277037). I'd like to see support for this added to the platform at the API level; adding a pref in core Eclipse would be nice too.
>I'd like to see support >for this added to the platform at the API level; adding a pref in core Eclipse >would be nice too. What do you think is the difference between the two? We won't work on this until we get a patch.
(In reply to comment #8) > >I'd like to see support > >for this added to the platform at the API level; adding a pref in core Eclipse > >would be nice too. > > What do you think is the difference between the two? Even if Eclipse doesn't expose a pref that affects all code assist, an API level change (along the lines of what I was suggesting in that dupe bug) would let me change code assist behavior in our app. (Right?) > We won't work on this until we get a patch. I'll see if I can carve out some time in a month or two.
> an API level change This is not an option. The API has to be kept stable.
New Gerrit change created: https://git.eclipse.org/r/66555
I came across this bug and think I have found a solution. I have submitted a patch that I think addresses this in the most straightforward manner. Please take a look at the Gerrit change and let me know what you think. Thank you.
New Gerrit change created: https://git.eclipse.org/r/69389
I have posted a solution in the gerrit link above.
(In reply to Eclipse Genie from comment #13) > New Gerrit change created: https://git.eclipse.org/r/69389 I've abandoned that change. Please upload the new version to the original change: https://git.eclipse.org/r/#/c/66555/ so that previous review comments are in the same change.
