Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 43625

Summary:	[EditorMgmt] Next and prev window commands should be able to do tab order rather than last used order
Product:	[Eclipse Project] Platform	Reporter:	Brian Pontarelli <brian>
Component:	UI	Assignee:	Platform UI Triaged <platform-ui-triaged>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	champion, daniel_megert, djspiewak, iyers, jens, joerg.heinicke, markus.kell.r, mic, thevilkacis
Version:	3.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 2000
Whiteboard:

Description Brian Pontarelli

2003-09-24 22:31:29 EDT

The next and previous window commands appear to use a stack to keep track of 
ordering. This behavior allows you to select the next and previous editor 
windows using the order in which they were last viewed. Many other editors 
support this functionality including Visual Slick Edit. This causes this type 
of behavior:

The tabs look like this:
file1    file2    file3    file4

The order in which the files were last viewed is
file3    file2    file4    file1

The user is viewing file1 and hitting ctrl-f6 and releasing it will take them 
back to file4.


However, with a large number of files (15+) open at a time, this becomes 
tedious when attempting to return to the the editor windows near the beginning. 
In fact, this can be an enormous source of frustration when attempting to 
quickly navigate back through all the files open. Here is why:

You have recently followed a long path through code and opened 20 or so files. 
You've also edited various files along the way including many jumps around 
within files. Now you want to go back over each of the files. You could use the 
back button, but this is teadious because of all the jumps inside files that 
you made while you went. So, you must first go to the last editor by hitting 
ctrl-f6, then to the second to last editor by hitting ctrl-f6, ctrl-f6 and so 
on until you must hit ctrl-f6 N times to return to the first file opened, where 
N is the number of open editor windows.

It would be nice to be able to control how this functions better. Something 
such as a preference like, "Next/prev editor uses tab order" would help 
immensely. Another option to speed up this process would be something such 
as, "Next/prev editor occurs before key release". This would mean that prior to 
releasing the ctrl key, the editor would flip. This allows a user to hold the 
ctrl key and continually hit F6 until the correct editor window is found either 
by the name in the tab or visually by the contents of the window. 

Of course this last option would not effect the way that the stack ordering (or 
last viewed ordering) works. A scenario would be something like this: 

User holds ctrl key and hits F6 a few times to find the right file by observing 
the contents of the file.
Once the user releases the ctrl key, the current editor would be placed on the 
top of the stack.

Comment 1 Douglas Pollock

2004-09-28 11:31:48 EDT

*** Bug 70093 has been marked as a duplicate of this bug. ***

Comment 2 Douglas Pollock

2004-09-28 12:35:01 EDT

*** Bug 59623 has been marked as a duplicate of this bug. ***

Comment 3 Jörgen Rapp

2004-10-27 17:49:09 EDT

ctrl-arrow up, down is functional when the popup is visible. 
How about also adding ctrl- (page down, page up, end, home)?

Comment 4 Daniel Spiewak

2007-02-16 12:07:40 EST

Ctrl-PgUp and Ctrl-PgDn work just fine.  I haven't tried end and home but they probably work (given the condition of the rest of the fix).  This bug should be closed.

Comment 5 Dani Megert

2007-11-21 11:57:56 EST

This is not an enhancement but rather a bug which makes 'Next/Previous Editor' hard to use.

Comment 6 Daniel Terhorst

2007-11-21 17:41:40 EST

CTRL+PageUp/CTRL+PageDown do not behave as described in the bug report when sub-tabs are involved (that common case is broken -- Bug #199499); furthermore, they are unmappable keys (unlike CTRL+F6/CTRL+Shift+F6) and there are no plans to fix that (Bug #86248), so they cannot be mapped to convenient keys like CTRL+Tab/CTRL+Shift+Tab even if they worked right.


Adding the options described in this bug report would fix what I consider one of the biggest usability frustrations in Eclipse: poor tabbing support. 

For me, cycling through files in the order of the last viewed is awkward and counterintuitive, and a poor substitute for the standard tabbing behavior that even Firefox and IE 7 can agree upon (and at least a few non-browsers I can think of).

I can't think of a single other problem Eclipse has that's so glaring. Yuck.

Comment 7 Dani Megert

2007-11-22 09:30:29 EST

>This is not an enhancement but rather a bug which makes 'Next/Previous Editor'
>hard to use.
I have to take this back: actually I also use LRU ordering as it is now from time to time and hence, we should just add a new Next/Prev navigation style and not change the existing one.

Comment 8 Dani Megert

2007-11-22 09:32:03 EST

*** Bug 114308 has been marked as a duplicate of this bug. ***

Comment 9 Markus Keller

2007-11-22 09:51:19 EST

The Next/Previous Editor actions implement a stack ordering and they should not
be changed. They are analogous to e.g.
- Windows's Alt+Tab and
- Firefox's Ctrl+Tab.

I would not add an option to change the behavior of these actions, but rather
add two new actions "Next/Previous Part", which cycle through the parts in one
stack (e.g. the editor area or a view stack) and don't show any popup, like
- Windows's Ctrl+PageUp/PageDown (in the absence of nested tab folders) and
- Firefox's Ctrl+PageUp/PageDown.
These commands should also work in dialogs (e.g. the Search dialog) where they should behave like Ctrl+PageUp/PageDown today.

Their default mapping could be Ctrl+PageUp/PageDown, and users who really want
to get the native Windows behavior could unmap them.

Comment 10 Susan McCourt

2009-07-09 19:03:22 EDT

As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009

Comment 11 Boris Bokowski

2009-11-17 12:59:32 EST

Remy is now responsible for watching the [EditorMgmt] component area.

Comment 12 Eclipse Webmaster

2019-09-06 16:18:30 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

Comment 13 Jens Lideström

2021-11-05 11:28:16 EDT

This is fixes in current versions of Eclipse, when the setting *Perferences > General > Appearance > Show most recently used tabs* is disabled.

I'm closing this issue.