Community
Participate
Working Groups
While testing the fix for bug 480348, I found that moving from an occurrence annotation to a non-occurrence one will change the showing occurrences. Consider the following snippet: function dorename() { var bar = 12; bar++; } dorename(); var o = { r: function() {dorename();} }; Steps: 1. select the first 'bar', all of its occurrences are marked (OK) 2. Hit Ctrl+ twice 3. notice your original occurrences are gone and 'o' is marked (there is a warning annotation on that line). I understand that the bindings are there to move through all annotations, but it is a bit frustrating if you accidentally jump away from occurrences you care about to another annotation and lose what you were looking at.
(In reply to Michael Rennie from comment #0) > Steps: > 1. select the first 'bar', all of its occurrences are marked (OK) > 2. Hit Ctrl+ twice That should read 'Ctrl+.'
I think the only way to fix this is to make it possible to navigate by type of annotation. I'm not sure if we want to go there? For example, you wanted to go to the next "occurrence annotation". Since occurrences change when the caret changes, you were ok after the first ctrl+. because the caret was still on bar. But when you typed ctrl+. again, you went to the next annotation of any type (which was a warning, and not another occurrence of bar), and the caret was on "o" so occurrences of "o" are marked now. So ctrl+. and ctrl+, are behaving as expected. Do we want to have some kind of modal annotation navigation? i.e. on Mac, it might be nice to use the rotor to select Errors, Warnings, Occurrences, etc. and then ctrl+. goes to the selected annotation type. Bit of a pain on Windows without the rotor - it becomes a bit too onerous to change modes before navigating if you have to go select from a combo or something first. I'm thinking maybe the current behavior is ok? (It would encourage folks to fix their errors and warnings if they want to navigate by occurrences <grin>).
I have to admit that it's a bit weird, however. I just opened a large-ish file (textStyler.js) and started typing ctrl+. and it's strange to go through: - a warning on "result", then a couple of occurrences of "result", - then a warning on "parent", then a couple of occurrences of "parent", - then a warning on "name", then a couple of occurrences of "name"... Suggestions welcome.
Please also see Bug 488139.
Eric, and ideas on how to make this less weird? I take back what I said in comment 2 about this behavior maybe being ok - it's not ok. It's the kind of thing that messes people up and makes them stop using a feature. ;)
and ideas => any ideas
Let me take a look at this. From what I've read it seems that Ctrl+. iterates through *both* annotations and occurrences and landing on an annotation can also cause occurrence annotation to be both destroyed and / or created. About the only thing that comes to mind is perhaps we can adjust Ctrl+. to work differently if it was invoked against an actual 'syntax' annotation versus an occurrences annotation. The command would then only go from error / warning annotations or occurrences depending on the *first* use... ?
That sounds like a good solution. What are all of the types of annotation? i.e. Seems to me the user would want to traverse through both errors and warnings together (?), but occurrences separately. There's 'tasks' as well, aren't there? Like //TODO's? We probably want to think about all of them to see if your "first type" idea works for the rest of the annotation types.
THere are actually a ton of different annotations (we use them for essentially everything that needs to keep its place sync'd with file edits... After talking with Grant we'll likely make the behavior for 'syntax annotations' mean 'that which has an adornment in the left-most gutter'. This would cover errors, warnings, and TODO's (is there anything else ?). Annotations like the folding indicator are in a different gutter and so wouldn't participate in Ctrl + .
One thing that needs definition for this is how to determine when to 'reset' the state. In order to determine the type of iteration we want on the 'first' Ctrl + . we need to know what 'first' means... My first cut will use two things to determine when the user is no longer iterating; any change in the input (file) contents and / or any change in the cursor position not done through an iteration.
Just noticed that you can also mess up the work flow(s) by using the 'Find' dialog to show search matches (which are again annotations. I'm going to adopt the same logic to handle this; if you *start* iterating on an occurrence (with no matching error / warning) you only iterate occurrences. Likewise with starting on a search result; start with the cursor on a search result you onl iterate search results. Also, when iterating across errors/warnings we'll skip both occurrences and search results.
OK, I have a fix for the main issue of having occurrences trash the iteration of errors / warnings. It works by introducing an 'iterationMode' that, once set, remains constant through consecutive '.'s. For now the mode resets if a Ctrl + . is issued and the caret has moved from the position the last one set. If necessary we could also reset if the document changes (goes dirty). There are three modes: Errors / Warnings Occurrences Find Matches We might want to add a mode that iterates TODO's and Bookmarks as well...
> We might want to add a mode that iterates TODO's and Bookmarks as well... Yep, I think grouping those together makes sense. Might as well implement it while you are in there. :)
To Test: put the cursor on a warning / error annotation. .'s now only go through warnings and errors, skipping occurrences or find results. Put the cursor on an occurrence annotation ( that does *not* also have a warning or error). .'s now iterate through the occurrences Same thing for find results One issue I had was that trying to test moving the cursor to 'open space' so prove that I default to warnings and errors almost every place I clicked on caused an occurrence to appear. I guess it's natural, we change vars and such but rarely edit 'if'.
OK, i've just pushed the code to allow iteration over tasks; if you put the caret in side the "TODO" part of the comment then Ctrl . will go through your tasks and Bookmarks.
Is this completely fixed now?
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04114.html
