I think it should be possible to invoke default gutter action on a line by click
on gutter in cases when the gutter contains some other actions like overrides
method, javadoc hints etc.
Debugger can insert fields and methods breakpoints by gutter but if there is
ae.g. overrides method annotation on method definition line user cannot use it
and he/she must use popup menu. It is quite confusing, one feature blocks
another one here.
Is it possible to detect if the mouse click was on annotation icon or not and if
it was in some distance of the icon use the default action instead of the
We could do that, but I am not sure if it is going to be less confusing. Funny
enough, sometimes javadoc hints can't be triggered by clicking on them, all you
get is a method breakpoint. I can't reproduce it reliably though.
IMO, clicking an annotation icon should do what the annotation is meant to do.
People see the icon, know what it means and click it because they want to use
it. The fact that an empty gutter sets/removes a line breakpoint is a bit
different story. I think most of the confusion comes from the fact that
adding/removing breakpoints is done from the editor popup menu and not the
gutter popup menu. Editor bookmarks for example are available in the gutter
menu. We could have something similar for breakpoints too.
As I remember toggle line breakpoint was always default action for click on gutter. The question is if the 'privileged
position' of breakpoints will be kept in future or bookmarks and profiling points will be placed to the same level.
*** Issue 118444 has been marked as a duplicate of this issue. ***
IMO the default action should be invoked after click on gutter free space next to an annotation icon. There is no reason
why the annotation icons should occupy so wide area - whole gutter line. Icons are usually sensitive only in rectangle
area defined by their images' width and height.
*** Issue 120128 has been marked as a duplicate of this issue. ***
*** Issue 120132 has been marked as a duplicate of this issue. ***
*** Issue 121985 has been marked as a duplicate of this issue. ***
*** Issue 130455 has been marked as a duplicate of this issue. ***
moving opened issues from TM <= 6.1 to TM=Dev
*** Issue 142446 has been marked as a duplicate of this issue. ***
*** Issue 139078 has been marked as a duplicate of this issue. ***
*** Issue 141456 has been marked as a duplicate of this issue. ***
*** Issue 145204 has been marked as a duplicate of this issue. ***
Just to bring some attention on this issue.
There are plenty of dups, but no votes ? I will set the first.
This should be finally fixed for 7.0.
*** Issue 164796 has been marked as a duplicate of this issue. ***
*** Issue 172671 has been marked as a duplicate of this issue. ***
wow ... 10 duplicates so far
*** Bug 187180 has been marked as a duplicate of this bug. ***
*** Bug 210455 has been marked as a duplicate of this bug. ***
It seems unfortunate that this has been seen by several people as a problem for the past five years. This problem is still present in 7.2 dev. My comment below relates to c++, but Alex Simon points out that the same holds for java.
Whenever I search for something, the editor places a light bulb in the left
margin so that I can easily add an editor-fold comment. When writing code, I
can easily ignore this. However, when debugging, I most often search for
variables/methods/etc in order to place a breakpoint.... and its not possible
to set a breakpoint on any line that already has a light bulb in it. See
You can work around this by clicking on another line first or hitting the hot
key for setting a breakpoint, but this seems pretty irritating, because the
editor is suggesting that this is something I always want to do when I search,
and this is never something I do.
I think there are a couple of very good solutions that preserve this feature
for its fans:
- In java, there are usually multiple options that pop up with alt-enter.
Perhaps this should include an option for setting a breakpoint.
- Better, IMO, would be to allow the user to click in the column but provide a
way that a breakpoint can still be set.
- Even better, IMO, is a UI option for turning off this feature.
I note that, while debugging, the light-bulb does not show up for every search
target. Stop debugging and the light bulbs show up again.
Created attachment 118142 [details]
Click on error badge unexpectedly sets breakpoint
(In reply to comment #21)
> However, when debugging, I most often search for variables/methods/etc
> in order to place a breakpoint.... and its not possible to set a
> breakpoint on any line that already has a light bulb in it.
I often have the contrary problem. I see the red compile error badge, click on it, expecting a solution suggestion, but have set a breakpoint.
The current gutter annotation behavior is inconsistent and in some ways counter-intuitive as a whole. The gutter area to the left of one line effectively has a separate left and right part. In some contexts these parts act as one (e.g., with just the single error icon displayed on the right, clicking either on the right [the error icon itself] or left is interpreted as breakpoint toggle what rarely makes sense in this case), in others the two parts react differently (when the "multiple annotation" black arrow is shown and one of the icons is displayed to the left of it, then clicking the arrow has different meaning than clicking the icon). Generally there indeed is enough space in the gutter to distinguish the click on the left from the click on the right, or more precisely the click on a single icon from the click in the area left from it. Therefore, it is possible to consider the following proposal.
To prevent user confusion, and to make handling of gutter annotation icons more intuitive and less prone to behavior perceived as unexpected by users, I suggest the following changes:
1) a click on an icon should never trigger an action unrelated to that icon
2) only the click to free area is interpreted as default (breakpoint toggle), i.e., a breakpoint is set only on click anywhere in a gutter area without any icons, or on click in the left empty space if there is just one icon on the right (including the black arrow alone on the right, see below). Clicking an existing breakpoint toggles it for free space (even if there remain multiple icons assigned to this line, in such case this leads to black arrow displayed alone on the right, see below). Note that if there exists a breakpoint and is the only icon in the gutter, then a click in the free area on the left from it is ignored.
3) if there are multiple annotations in the gutter as indicated by the black arrow on the right and one of the icons on the left, then clicking the arrow cycles through all relevant icons including one more previously unsupported state: no icon = free area. This state would enable setting a breakpoint if there is not one yet. Note that free area can be reached using the black arrow ONLY if there exists no breakpoint for this line (or as result of removing an existing breakpoint, e.g. by toggle).
Advantages of the above proposal:
a) clarity - users always know that a click on an icon is related to that particular icon. Note that the proposal does not restrict the ability to set breakpoints in any way - on lines with a single icon this is achieved through a click to the left of the existing icon, in case of multiple icons this involves cycling for free area using black arrow first, but this still is more convenient and discoverable than what is necessary now - to think where and when to click as there is always an icon displayed while some of them lead to breakpoint toggle while some do not.
b) this opens up possibilities for future adding of menus to any icon that currently does not have one, if needed. One area that could benefit immediately is, e.g., bookmarks, where a click on the bookmark would make it possible to rename the bookmark etc.
- toggle-delete of nondefault bookmarks (=bookmarks customized by user in properties window) should be undoable or should be made less harmful in some other way - currently the accidental deletion of complicatedly configured bookmark is all too possible and annoying
- Ctrl-Shift + click in gutter regardless its contents would set/toggle a bookmark. Note that customized bookmarks (with assigned name and/or with shortcut) should be prevented from accidental delete in the same way as breakpoints
- method breakpoint Properties dialog permits to check All Methods For Given Class. This creates an entry in the Bookmarks window, but it is not indicated in the gutter in any way - not even is the checkbox checked on next opening of the same dialog. Not indicating this in the gutter is OK (it would be a unintended visual mess), but it should be reflected somehow at least in context menu; e.g., whenever the user right-clicks the gutter belonging to line with a method, the menu should display entry Method Brakpoint->All Methods For Given Class Enabled or so. The similar problem may apply to any other bookmark type that just appears in the Bookmarks window and not anywhere in context menus reachable from gutter
- the right-click menu should generally provide more exact control over Breakpoint and Bookmark specific functionality. I would prefer the respective submenus to be extended by the following items: Bookmark->Add Bookmark (item disabled if bookmark exists for this line), Bookmark->Remove Bookmark (item disabled if no bookmark exists for this line), Breakpoint->Add Breakpoint (item disabled if breakpoint exists for this line), Breakpoint->Remove Breakpoint (item disabled if no breakpoint exists for this line). For better clarity also rename Bookmark->Next Bookmark to Bookmark->Go To Next Bookmark and Bookmark->Previous Bookmark to Bookmark->Go To Previous Bookmark
Comments, thoughts, have I overlooked something ?
Created attachment 120367 [details]
Proposed API change.
I have attached a patch that implements the following from Petr's proposal:
1. clicking on an annotation icon will only invoke an action associated with that annotation (see below), if any. The action may choose to delegate to other action (see below). The intent is to ensure that clicking on an annotation will never do anything not related to the action.
2. when clicking on the free space next to the annotation (or to the free space if there is no annotation), the default action will be invoked, which is expected to set a breakpoint.
3. clicking on the free space when a breakpoint exists on the line will not invoke the debugger's default action, i.e. it will do nothing. It is necessary to click on the breakpoint to unset it. (Petr, that is what you proposed, right?)
This all is based on three new values that can be set to the actions registered in "Editors/.../GlyphGutterActions":
-"default-action": if true, this action will be invoked when the free space is clicked
-"default-action-excluded-annotation-types": an array containing annotation types. When any of the annotations on the current line has any of these type, this action will not be invoked when the free space is clicked. (See below for combined annotations unrolling.)
-"supported-annotation-types": an array containing annotation types. When an annotation is clicked, the first action that contains its type in the supported-annotation-types attribute is invoked.
-I am not sure what is the compatibility level of the "Editors/GlyphGutterActions" API - I would expect friend as is the rest of the legacy editor APIs? Currently the patch contains a certain level of backward compatibility: if there is no fitting action under this new scheme, the first legacy action is invoked. If this is kept, it is only for modules outside the std. distro, all actions in the std. distro must be updated to fulfill the UI requirements.
-the actions under the new scheme do not need to delegate to "next" action when they have nothing to do (because they are always called on "their own" annotations in the new scheme). But I kept the delegation for now, to help the backwards compatibility. Should probably be reconsidered to prevent unintended delegation.
-the "supported-annotation-types" and "default-action-excluded-annotation-types" do not need to contain any combination annotation types - these are unrolled automatically. Only the "base" annotation types need to be specified.
Please review, thanks.
I have integrated the above change:
I think this resolves the most pressing needs.
*** Bug 210103 has been marked as a duplicate of this bug. ***
(In reply to comment #23)
> if there remain multiple icons assigned to this line, in such case this leads to black arrow displayed alone on the right
Only a small enhancement: The tooltip of the black arrow should also display all the name/descriptions of the actions/annotations/breakpoints on this line.
(In reply to comment #28)
> Only a small enhancement: The tooltip of the black arrow should also display
> all the name/descriptions of the actions/annotations/breakpoints on this line.
I endorse this.