Community
Participate
Working Groups
Currently you can press Ctrl+space multiple times to cycle through different types of completion proposals e.g. Java proposals, Template proposals, SWT proposals. Quick fix/assist, Refactor actions and Source actions all can be said to do code transformations. The difference between them is also fuzzy as many of the Refactor and Source actions are available as a quick assist. Currently each is accessible via a different shortcut and in case of Refactor and Source menu the default shortcut has 3 keys, which is harder to press/remember than a 2 key shortcut. We should make all 3 accessible via one shortcut by chaining them together just like different types of content assist proposals. This way we have to advertise only one shortcut for code transformations, and the user also has to remember only one shortcut. Possible solutions * Use Ctrl+1 to chain these together - When there is no error on the line, 2nd Ctrl+1 shows the Refactor menu, 3rd shows Source menu and 4th goes back to quick assist popup. - When there is an error on the line, 2nd Ctrl+1 jumps to the error, 3rd jumps back to the original location and shows the quick assist popup, 4th shows the Refactor menu, 5th shows the Source menu, 6th shows the quick fix/assist popup at the original location. (Or do we want to jump to the error location at 6?) * If we do not want to change behavior of Ctrl+1, we can possibly use Ctrl+2. With Ctrl+2 we can show quick assists on the first press and also include any quick assists whose shortcut is Ctrl+2 plus another key. After discussing this with Markus and thinking about it, I lean towards using Ctrl+1 for this. (One argument against doing this would be to add appropriate actions in Source and Refactor menus as quick assists. While we can do that, it is not always possible e.g. Surround With actions. If we add everything as quick assist then the quick assist popup will become too cluttered)
In contrast to the large 'Source' and 'Refactor' menus, the Quick Assists are supposed to be the best fitting or at least most popular choices from both menus. I'm not sure I want this to be replaced with two separate large lists as it probably gets harder to choose the right proposal. If at all I'd probably want Quick Fix > Quick Assist > Refactor > Source. Having said that, I'm fine trying this out but we should implement it as a new command, so that the user can decide whether to use the old Ctrl+1 behavior or use Ctrl+1 (or whatever key binding) for the new behavior. Regarding Ctrl+2: I don't know how many use the existing Ctrl+2,[F|L|R] shortcuts, but those would be impacted. Along the same line of bug 353759 we might also consider displaying refactoring proposals differently than other (less exact) quick assists.
> - When there is an error on the line, 2nd Ctrl+1 jumps to the error, 3rd jumps > back to the original location and shows the quick assist popup, 4th shows the > Refactor menu, 5th shows the Source menu, 6th shows the quick fix/assist popup > at the original location. (Or do we want to jump to the error location at 6?) Off-by-one: 1st Ctrl+1 already jumps to the error/warning, 2nd back to original, ... . At the end, I wouldn't jump to the error location again, i.e. error, orig., refactor, source, orig. quick assists, refactor, source, ... > I'm not sure I want this to be replaced with two separate large lists as > it probably gets harder to choose the right proposal. The lists shouldn't be that large if we show only the applicable source actions / refactorings (like in the context menu or the quick menus).
(In reply to comment #1) > Having said that, I'm fine trying this out but we should implement it as a new > command, so that the user can decide whether to use the old Ctrl+1 behavior or > use Ctrl+1 (or whatever key binding) for the new behavior. Ctrl+1 behavior is not really changed, at least not the behavior of 1st press (and the second when there is an error). We just change the behavior when you press Ctrl+1 multiple times, which a user does not do today.
> Ctrl+1 behavior is not really changed, at least not the behavior of 1st press > (and the second when there is an error). Ah, yes - see it now. In that case we don't need a new command.
See also bug 255123, bug 367671, bug 367672 for requests to provide quick assists for refactorings. See bug 255123 comment 6, bug 255123 comment 7, bug 255123 comment 8 as to why we should not fix those bugs. However, such requests do add support for fixing this bug :-)
