Community
Participate
Working Groups
Moving with CTRL-, and CTRL-. is very good, but it will neither span across files nor sync up with the Problems view. It would be very productive if I could move to next and previous problem (syncing with the Problems view), but I just don't see anyway other than a clunky "CTRL-F7, down/up arrow, ENTER". Zorzella
The editor doesn't know about the problems view. So using CTRL-, and CTRL-. in the editor won't be able to use the information in the problems view. But the problems view could support CTRL-, and CTRL-. as it is done in the search view.
There are two ways this could work. Either this could work the same way as the Search view. This is ideal from a key binding perspective, as it does not lead to competition between two different commands for the same key binding. Or, an entirely new command could be defined.
Being able to go up and down while focus is on the Problems view is of some, but limited value (it basically supplants arrow key + ENTER). I'm sure there ought to be a way to have a command (that one can bind to a key) that afects a view that does not currently hold the focus. In fact, I know there are some like that, e.g. CTRL-E will always bring a drop-down menu of a file to edit in the editor, even if you are in another view. To make this very explicit, what I think would be very useful is a key that can be used while editing a file that would jump to the next problem (quite possibly opening an unopened file) and leave the focus on the editor, with the problem selected (much like CTRL-,/. do). Zorzella
There are no plans to work on this feature currently
To make Ctrl+, and Ctrl+. work like in the Search result view, they would also have to open the editor without passing focus away from the Problems view.
What I am asking for is different from using CTRL-,/. in the search view, but has similarities. I want to, while having the focus in the editor, navigate back and forth between entries in the problems view, having the focus remain in the editor. In fact, something like this would also be useful for navigating entries in the Search view. I find myself, very often, doing: CTRL-Q S (go to search) CTRL-+ (go to next entry) SHIFT-CTRL-E (focus back to Editor) I wish I could to do all this with a single keystroke...
*** Bug 218492 has been marked as a duplicate of this bug. ***
*** Bug 250770 has been marked as a duplicate of this bug. ***
This bug is still a problem. Would it be possible to have it looked at again?
re-visit
You can almost do this kind of thing in a single bound keysequence, if you were using the Emacs+ plugin, and the "Show View" command worked differently. The Emacs+ plugin lets you record keyboard macros, which you can bind to a single keysequence. Unfortunately, I discovered that the "Show View(Search)" (for instance) command is a "parameterized" view, so when you execute "Show View (Search)" in a macro, it just brings up the "Show View" dialog, instead of showing the Search view. Emacs+ doesn't yet support parameterized commands. When it does (I don't know how long that will take), then technically you could use Emacs+ to bind a single key sequence to a command which will step to the next problem or search occurrence, from within the editor view.
If you're interested, the Emacs+ plugin now (I've been talking to Mark Feber about this) can provide this feature, although it has its limitations. I've tested the ability to record a keyboard macro which executes the following steps: 1. Show the search view. 2. Go to the next occurrence. 3. Activate the editor view. I've bound a key to the function to execute the last recorded keyboard macro, so with a single key sequence pressed from within the editor view, I can go to the next search occurrence and still have my focus in the editor view. Doing this for the problems view instead of the search view is a trivial difference. The limitations that I know of are: 1. The macro actually switches from the editor view to the search view and back again. As a result of this, you can easily confuse it if you press the key quickly before it's gotten back to the editor view. It's easy to rectify if that happens, but it just means you can't press the key quickly to advance through the list quickly. 2. There's currently no way to store recorded keyboard macros across sessions. It only takes a few seconds to record the macro in a new session. I still believe that we'd be better off with a "native" implementation of this feature, so the stepping through search occurrences or problems could be done entirely within the editor view, without jumping the focus out and back. As this ticket has been around for 5 years now, I have a feeling we'll be waiting a little longer for this. :)
Some time ago, we did some brainstorming about this problem, but now I realize we never posted it: Here's a list of bugs related to this problem: Bug 281556: Still no keyboard navigation for non-focused window Bug 111046: [KeyBindings] keyboard shortcut for next match when searching Bug 115202: [Markers] [Commands] Next/Previous problem key binding Bug 24753: [Markers] Add Show Next/Previous Buttons Bug 193608: Need easy way of navigating back from editor to view which handed it control Bug 32330: [Markers]ctrl-. does not work automatically across files Bug 309608: Allow "Next" in the search view to be executed (and bound) outside of the search view Solution proposal: - keep existing Next/Previous (Ctrl+./,) unchanged - new global commands and main toolbar actions Next/Previous Item (e.g. Ctrl+Alt+./,) - toolbar button is a dropdown with a menu of - a radio item for each supporting view (Problems, Search, Synchronize, Debug, JUnit, ...) - radio item for 'Last view'. Unsure yet what the 'last' view should be: - (Dani): last view from which an item has been opened? (opened by double click, via Next Item, etc.) - (Markus): last view that had focus and supports global navigation - views can participate in this service via an extension point (they need to implement the selection update in their widget and the opening of the editor and select/reveal of the text range). - Package Explorer and Browsing views could also support the new commands and jump to next/previous problem in the visible items order
*** Bug 332667 has been marked as a duplicate of this bug. ***
*** Bug 6698 has been marked as a duplicate of this bug. ***
