Community
Participate
Working Groups
Created attachment 276840 [details] see image Use the project attached on bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=542439 1)Keep the initial cursor location between var and x ( dont select anything) 2)Press Control+1 Cursor location moves to the comment section and I get many random suggestions. See image attached
That's the feature where the caret first jumps to any error/warning available on the line to show the quick fixes for that problem. You need to press Ctrl+1 once again to come back to the original position to see any quick assists. The same is also described in the message detail at the bottom of the popup.
(In reply to Noopur Gupta from comment #1) > That's the feature where the caret first jumps to any error/warning > available on the line to show the quick fixes for that problem. I was thinking the same, but from Java p.o.v. there's no problem to which the caret should jump. So, why exactly is the caret jumping to that particular location? Is it a spelling error ("var" not in dictionary)? If so, may I suggest to exclude spelling mistakes from this caret jumping?
I don't think it should jump to the near error or warning without user wanting it to jump. The 1st quick assist should be what it is ( no suggestions available) ( similar to when the quick fix jumps to the original position). And there the user can see he or she can press Control+1 again to jump to the nearest warning or error.
(In reply to Vikas Chandra from comment #3) > I don't think it should jump to the near error or warning without user > wanting it to jump. The 1st quick assist should be what it is ( no > suggestions available) ( similar to when the quick fix jumps to the original > position). And there the user can see he or she can press Control+1 again to > jump to the nearest warning or error. I like that Ctrl+1 is not fussy about exactly hitting the error location, so if I see a fixable error, I just go to the beginning of that line and am happy about the proposal regarding the error further right. Most the time this is what I want. OTOH, I only learned through some bz discussion, that quick *assists* can be activated on that same line by pressing Ctrl+1 again (In case this learning happened after bug 201878 it only proves that I couldn't / didn't read the bottom line of the popup ;p ) From UX perspective two aspects seem to compete: (1) first present the most likely proposals, which IMHO would be the error-related proposals (2) understand the gesture exactly as performed: offer assists available HERE I believe giving priority to (1) is fair, if "most likely" is well implemented. In comment 2 I only questioned, if a spelling error in a (comment of a) Java file is actually of high relevance, compared to anything coding. Similarly, one could argue that info messages are not most likely candidates for invoking quick fix. Hence my proposal to not change the general logic, but fine tune which problems should have higher priority than quick assists at the current location. errors: certainly warning: maybe info: probably not spelling: no.
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.
