Community
Participate
Working Groups
200412011139: Mark occurrences annotations are not visible if located at the same line as the debug instruction pointer. The layer of the mark occurrences annotations should be higher than the one of the instruction pointer. Since the latter covers the whole line, it will be still visible if mark occurrences annotations are painted at a higher layer.
Personally I prefer the way it is now. Occurrences are on presentation level 4 (same as info). Debug's current IP is on level 6 to be on the same level as errors. Darin, why on same level as errors and not higher to be always on top? Maybe we should take the level as default and allow users to configure this on the annotation page.
I don't recall how we determined the level. Perhaps it is wrong. I'd like to see the breakpoints above warnings (not sure about errors).
Adapting summary
*** Bug 80512 has been marked as a duplicate of this bug. ***
*** Bug 84793 has been marked as a duplicate of this bug. ***
*** Bug 87502 has been marked as a duplicate of this bug. ***
*** Bug 91479 has been marked as a duplicate of this bug. ***
*** Bug 92553 has been marked as a duplicate of this bug. ***
We can show the layering on the annotation preference page and add 'Up'/'Down' buttons to configure the layering. Issues: - where do we place an annotation type that gets installed later i.e. how does its layer correspond to annotation layers changed via preferences - how do we treat extensions that will not provide a preference key
*** Bug 129222 has been marked as a duplicate of this bug. ***
*** Bug 151233 has been marked as a duplicate of this bug. ***
*** Bug 178850 has been marked as a duplicate of this bug. ***
*** Bug 186818 has been marked as a duplicate of this bug. ***
*** Bug 186835 has been marked as a duplicate of this bug. ***
*** Bug 208216 has been marked as a duplicate of this bug. ***
*** Bug 239646 has been marked as a duplicate of this bug. ***
*** Bug 318575 has been marked as a duplicate of this bug. ***
*** Bug 369721 has been marked as a duplicate of this bug. ***
Please make it possible to see all of the markers. One solution would be to make the gutter wider so that each marker can be displayed. Another solution would be to put a new icon that has the number of markers for that line. This second solution would give the user visual feedback when I place a new marker on the line.
There are two less involved solutions that would help immensely: 1. Allow users to specify ordering of annotations. 2. Give priority to DEBUG ahead of WARNING on the list. I think this is one should be simple and not controversial. User produced annotations should always have precedence over tool produced ones, especially if those annotations are merely informational.
> 2. Give priority to DEBUG ahead of WARNING on the list. I think this is one > should be simple and not controversial. I disagree. For me the warning is at least as important as the breakpoint.
(In reply to comment #21) > > 2. Give priority to DEBUG ahead of WARNING on the list. I think this is one > > should be simple and not controversial. > > I disagree. For me the warning is at least as important as the breakpoint. By default, a Warning is also visible in the editor and the overview ruler, while a breakpoint is not. So a breakpoint will not hide a warning completely, but the other way round is true.
(In reply to comment #22) > (In reply to comment #21) > > > 2. Give priority to DEBUG ahead of WARNING on the list. I think this is one > > > should be simple and not controversial. > > > > I disagree. For me the warning is at least as important as the breakpoint. The issue isn't only 'importance', it's also usage. Think about it this way -- breakpoints are interactive jobs, warnings are background. Plus, breakpoints are far more sparse and sparse information should be preferred. > By default, a Warning is also visible in the editor and the overview ruler, > while a breakpoint is not. So a breakpoint will not hide a warning completely, > but the other way round is true. Exactly. It's pretty impossible to miss the existence of a warning. But as it is now, you can't even really tell the debug is there. That's a massive fail, IMO.
This bug has languished here for nearly 10 years. Please fix it, the "invisible" breakpoints makes debugging harder than it needs to be. Breakpoints should be obviously visible. For those of you who like it as it is, the obligatory link : http://xkcd.com/1172/
For me, this is particularly irritating when trying to find "Occurrences" and "Write Occurrences" using the overview ruler. For large files, a "Write Occurrence" surrounded by several "Occurrences" will be totally hidden in the overview ruler. A write-occurrence should take priority over a regular occurrence since it is a special type of occurrence. Similarly, if there is a warning on the same line as an occurrence, the warning marker will hide the occurrence marker in the overview ruler. In this case, the occurrence marker should take priority over the warning marker since it is more specialized and only showing while a particular variable/type/method is selected. i.e. When a developer has a particular item selected with his cursor, he cares more about finding the occurrences of that item than the existing warnings in the code.
(In reply to comment #25) > For me, this is particularly irritating when trying to find "Occurrences" and > "Write Occurrences" using the overview ruler. For large files, a "Write > Occurrence" surrounded by several "Occurrences" will be totally hidden in the > overview ruler. A write-occurrence should take priority over a regular > occurrence since it is a special type of occurrence. This appears to work exactly as you described?! I have changed the color of Occurrances to blue, Write Occurrances to greenish-blue under Annotations and have also turned on Use saturated colors in overview ruler under Accessibility. Write occurrances remain easily identifiable no matter how many read occurrances there are around or even on the same line. Do you perhaps mean search results?
Created attachment 246999 [details] How fixed occurrances would look (In reply to Darren Cunningham from comment #25) > Similarly, if there is a warning on the same line as an occurrence, the > warning marker will hide the occurrence marker in the overview ruler. In > this case, the occurrence marker should take priority over the warning > marker since it is more specialized and only showing while a particular > variable/type/method is selected. i.e. When a developer has a particular > item selected with his cursor, he cares more about finding the occurrences > of that item than the existing warnings in the code. I agree with this. Turns out this would be a really easy fix too: set write occurrences to presentation layer 7 and read occurrences on presentation layer 6. I have attached an animation to show how this fix works like in practice. See also the breakpoints which I didn't change. They disappear completely under the warnings as things get more and more cramped..
I have tested some changes to breakpoints to make them work well too and I've found out that putting breakpoint annotations on presentation layer 7 (same layer as compile errors) makes them draw on top of warnings also in the vertical ruler. This suggests read occurrence annotations should also be on layer 7, and based on that write occurrences should be on layer 8. These changes have been included in Evening-IDE, which is available here: http://overruler.github.io/Evening-IDE/
(In reply to Timo Kinnunen from comment #28) > I have tested some changes to breakpoints to make them work well too and > I've found out that putting breakpoint annotations on presentation layer 7 > (same layer as compile errors) makes them draw on top of warnings also in > the vertical ruler. This suggests read occurrence annotations should also be > on layer 7, and based on that write occurrences should be on layer 8. > > These changes have been included in Evening-IDE, which is available here: > http://overruler.github.io/Evening-IDE/ Timo, can you please provide a gerrit patch for your changes?
There's also the problem that search result arrows cover the breakpoint circles (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=208216 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=355884 ). A solution could be to use semi-transparent PNG icons? Is it feasible?
(In reply to Dani Megert from comment #9) > We can show the layering on the annotation preference page and add > 'Up'/'Down' > buttons to configure the layering. +1 > > Issues: > - where do we place an annotation type that gets installed later i.e. how > does its layer correspond to annotation layers changed via preferences Once the order is configurable, I wouldn't worry much about this and the default priorities. For newly installed annotation types, maybe give them highest priority so nothing gets lost. The preference reachability is already good, so users will hopefully not be too annoyed by over-emphasized annotations. However, with this approach it's still unclear what to do when multiple types get installed at the same time. > - how do we treat extensions that will not provide a preference key (In reply to Nathan Reynolds from comment #19) > Please make it possible to see all of the markers. One solution would be to > make the gutter wider so that each marker can be displayed. Another > solution would be to put a new icon that has the number of markers for that > line. This second solution would give the user visual feedback when I place > a new marker on the line. Also +1 for wider rulers (on demand). Even with configurable priority, it would be nice to have both vertical and overview rulers expand and shrink up to a configurable maximum number of annotations. When the maximum is exceeded, a generic overflow decoration as suggested in https://bugs.eclipse.org/bugs/show_bug.cgi?id=501498#c7 could be shown.
