Community
Participate
Working Groups
often I find myself with a couple scattered errors in a big file, ones I'm not going to deal with right away. Then I introduce a new one and don't notice, and the code fails. I come back to the editor to check for errors that may explain the problem. Currently I have to click the overview ruler to get to the error, then go to the other side to hover over the error. - It would be nice if I could hover over the overview markers and see the error text. - It would be nice to have a keybinding to navigate through the errors and invoke the explanation with the keyboard
Changing title of bug because the first part has been implemented in 0.3. Remaining issue is a way to navigate errors and invoke the explanation bubble by keystroke.
Note that we have added an annotation model to the editor. An annotation has type (error/bookmark/etc). Maybe this feature can work like the next/previous occurance of Eclipse, where the user selects what type (== annotation type) the next/previous action should act on. Anyway, using the annotation model should not be too hard to implement this.
Change the title since now we have other types of annotations (task, warning). It would also be useful to let the user choose what annotations are shown in the overview ruler. I expect it to get somewhat crowded as more annotation types are added.
*** Bug 367332 has been marked as a duplicate of this bug. ***
It would be nice to have this done for 0.4.
I've implemented the ability to navigate through the annotations via keyboard (and with screen reader support). I didn't do anything about the ability to select what kind of annotation you're traversing through. I've put it in the following commit in the bug338882 branch. https://github.com/max-li/orion.client/commit/a46fa31ab4a8671718e46edf533c78d5f68358c6
I've updated the patch to take into account some new changes and fix a minor inconsistency. The fix is in the bug338882_new branch, or alternatively can be found at: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?h=bug338882_new&id=291ab556f5a16b9771b56590fed5b0d368a1a69b Silenio, could you take a quick look and see if anything needs changing/improvement? Thanks.
I am not sure automatically showing the tooltip is a good idea. Often it hides the code where the annotation is and I feel lost (cannot see caret). The patch is navigating by line and showing a tooltip for all annotations in the line. It might be ok if it navigated by annotation and showed the tooltip for the current annotation alone. That way the tooltip could be offset from the caret location. Max/Susan, what do you think? Other comments: 1) maxWidth/maxHeight should be removed from the tooltip info. It is not used anymore by tooltip.js. 2) I do not think you need to check if(typeof(nextLine) === "number"). It is always a number. 3) Tooltips are showing folding annotations. Navigate thru the annotations of textView.js to see this (for annotation at line#5414) 4) No need to create prevAnnotations array (performance), since you just need the last annotation 5) The filtering by type needs to be improved. We need to be able to navigate thru custom define annotations, but I understand we should not navigate thru folding and current line annotations for example.
(In reply to comment #8) I've have switched to displaying each annotation one by one. I also fixed all of the first four comments (with the last comment being planned to be dealt with in a follow-up bug). Silenio, could you take a look and see if you prefer this? The fix is in the bug338882_new2 branch: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?h=bug338882_new2&id=c792bd68d0d920282690d18c693d917b86ca4a9a
Looks better this way. Here is a few small changes, but over it looks ok for me: 1) the target objects do not need the y property (not used): y: view.getLinePixel(nextLine) 2) we should move selection even if tooltip is not available 3) call convert() only once for (x,y) pair 4) should we offset the tooltip downwards a bit more?
(In reply to comment #6) > I've implemented the ability to navigate through the annotations via keyboard > (and with screen reader support). I didn't do anything about the ability to > select what kind of annotation you're traversing through. What are the keybindings? Note in Eclipse iterating through annotations is Ctrl+, and Ctrl+. so that is a good option unless it causes a conflict with browsers.
(In reply to comment #11) > What are the keybindings? Note in Eclipse iterating through annotations is > Ctrl+, and Ctrl+. so that is a good option unless it causes a conflict with > browsers. Yes, I picked Ctrl+. and Ctrl+, to coincide with the Eclipse keybindings. They don't seem to be used in any browser.
Pushed to master: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=285b4ff0ef5dfe2c17122c9dd22c7300317d5b08 I opened bug 376503 for setting which annotations to traverse.
Ctrl+ and Ctrl- are used by browsers to scale the font sizes. So I don't think it's a good keybinding choice but maybe I'm misunderstanding how it works, because Ctrl+ is still working for me to scale fonts...
(In reply to comment #14) > Ctrl+ and Ctrl- are used by browsers to scale the font sizes. > So I don't think it's a good keybinding choice but maybe I'm misunderstanding > how it works, because Ctrl+ is still working for me to scale fonts... duh, never mind. I see now that you were saying Ctrl+. and Ctrl+,
