Bug 219100 - [EditorMgmt] Improved listing of files opened in Editor
Summary: [EditorMgmt] Improved listing of files opened in Editor
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2008-02-15 09:54 EST by Bruno Melloni CLA
Modified: 2019-09-06 15:37 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bruno Melloni CLA 2008-02-15 09:54:49 EST
I have two suggestions that should be relatively simple to implement and significantly improve the ease of use of Eclipse.

Problem addressed:  When many files are opened in the editor simultaneously (i.e.: 10-15 files), it is painful to navigate from one to the other via the dropdown.

Suggestion 1:  Make a view available that may be placed on the left panel and that lists all the open files in the same way as the package explorer, navigator or project explorer.  It might even be a clone of the package explorer with a filter that limits the listed objects to those currently open in the editor.

Suggestion 2:  Modify editor's tabbing manager so that it would allow selecting the edge and make it a multi-row tab listing.  This would be similar to what happens when you drag the edge of MsWindow's Start bar at the bottom of the screen to make it use two or more rows - except that it would allow 1-n rows of tabs.  With this feature, a developer could choose to limit himself to one row of tabs and use either the pull-down or the view in suggestion 1 to pick those tabs that are not visible, or he could trade editor real-estate for the privilege of seeing tabs for all of his open files.

I hope you find these ideas valuable.  Thanks.
Comment 1 Remy Suen CLA 2008-02-15 12:33:01 EST
(In reply to comment #0)
> Problem addressed:  When many files are opened in the editor simultaneously
> (i.e.: 10-15 files), it is painful to navigate from one to the other via the
> dropdown.

What exactly is the "pain point" here? It is too much of a hassle to use the up/down keys to navigate? It seems that a user would still have to use those keys or the mouse if to select something in the case of suggestion one. You know Ctrl+E brings up the dropdown list, correct? There is also Ctrl+Shift+E but it doesn't really do the same thing.
Comment 2 Paul Webster CLA 2008-02-15 13:11:04 EST
(In reply to comment #0)
> I have two suggestions that should be relatively simple to implement and
> significantly improve the ease of use of Eclipse.
> 
> Problem addressed:  When many files are opened in the editor simultaneously
> (i.e.: 10-15 files), it is painful to navigate from one to the other via the
> dropdown.
> 
> Suggestion 1:  Make a view available that may be placed on the left panel and
> that lists all the open files in the same way as the package explorer,
> navigator or project explorer.  It might even be a clone of the package
> explorer with a filter that limits the listed objects to those currently open
> in the editor.

For this, I would suggest using CTRL+SHIFT+E ... it opens the list in a dialog as a navigation aid.  The other alternative is to use CTRL+3 (Quick Access) but that will only find an open editor, not show you a list.


> Suggestion 2:  Modify editor's tabbing manager so that it would allow selecting
> the edge and make it a multi-row tab listing.  This would be similar to what
> happens when you drag the edge of MsWindow's Start bar at the bottom of the
> screen to make it use two or more rows - except that it would allow 1-n rows of
> tabs.  With this feature, a developer could choose to limit himself to one row
> of tabs and use either the pull-down or the view in suggestion 1 to pick those
> tabs that are not visible, or he could trade editor real-estate for the
> privilege of seeing tabs for all of his open files.


This is about changing the presentation, and probably should be in its own bug.  You can usually find external plugins that contribute new presentations (there's one like visual studio) ... there might already be a presentation that look like you suggest.

PW
Comment 3 magic.bitbucket CLA 2008-02-15 13:16:59 EST
Hi ^^
I totally agree with the reporter.
The 'pain point' is that you can't change to a specific file with one keypress/click.
I often have 30+ files open, because otherwise I would have to locate the file from 1500+ classes for every little change - which takes a few seconds and isn't exactly comfortable.
The fact that ^E isn't sorted alphabetically, probably due to Mylyn, doesn't exactly make it more comfortable. Also Mylyn doesn't solve my problem, because there are often more than 20 files associated with a single task.

So I would welcome a list view for the open files or even smaller tabs which stack vertically if they run out of horizontal space very much ^^
Comment 4 Bruno Melloni CLA 2008-02-15 13:20:35 EST
Hard to explain the pain, but I'll try.  

First of all, this rarely is an issue with a small or a well structured/encapsulated project - in those cases you only work with a few files at a time, and it is easy to have their tabs all visible.  I've used Eclipse for years and have always been happy with the current functionality... until I joined my current assignment.

The pain mainly happens with a poorly structured, poorly documented project that you join in mid-stream and are forced to 'live with'.

In such scenario, in order to make sense of the code, you have to look at several files at once, jumping frequently from one to the next.  Sometimes you have to quickly switch between more files than the tabs allow.

This is where the pain starts:

a) As you select a new file, one of the old tabs disappears.  It may not be the one you last looked at, but it might be the one you planned to look at next.  Since file names tend to be longer than the tab, it is sometimes hard to tell 'which files' are still displayed as tabs. 

b) The list in the dropdown shows the files in mostly alphabetic order, but puts the visible tabs at the bottom.  This means that as you jump back and forth between files, the file you are trying to go to might not be in the same location in the dropdown as the last time you looked for it.  It is a minor nuisance, but it does break the train of thought.

c) If you are only looking at the tab or dropdown, you only see the file name (or part of it).  You don't see the Project (server, client, interface), or the package.  These things are important when you are trying to understand pre-existing code.

So... 

The purpose of *suggestion 1* is to give better view of the package structure, plus provide a -->constantly visible<-- list of all of the files open and give some ability to sort.

The purpose of *suggestion 2* is to give the developer the ability to see more tabs at once, so that he can order them in a way that makes sense to him... for example, order then in the same sequence as the code executes.  That way when he starts making changes he has a clear mental image of how the pieces fit together.

Sure, 90% of developers will not care about these issues, but the remaining 10% will appreciate features that make dealing with messy code easier.  These features would.

I hope that explains what I meant by 'pain' with the current mechanism, when dealing with ugly code.
Comment 5 Paul Webster CLA 2008-02-15 15:39:58 EST
(In reply to comment #4)
> 
> In such scenario, in order to make sense of the code, you have to look at
> several files at once, jumping frequently from one to the next.  Sometimes you
> have to quickly switch between more files than the tabs allow.

That's why I'm asking if CTRL+SHIFT+E works better.  You get a solid list, typing will still find a specific file, and the entire thing is sorted alphabetically by default and can be sorted by path (project first) as well.

It avoids a, doesn't have b, and satisfies c

Later,
PW

Comment 6 Bruno Melloni CLA 2008-02-15 16:09:18 EST
I looked at CTRL-SHIFT-E.  

- It closes when you select a file, so it does not help with 'keeping all the files in mind'.  A panel/view would.

- It always opens at the same size, making long file names and paths hard to read.  And it only fits 11 files before you have to manually expand it or scroll.

Given those issues I'd say it helps some, but not enough.  Yet, it is nice... I'll definitely use it for other needs.
Comment 7 Boris Bokowski CLA 2008-02-20 17:11:13 EST
There is substantial overlap between this bug and a number of older ones, for example:

bug 10941  tabs: Editor view for managing editors
bug 68684  tabs: Remove the MRU tab reordering code from the default presentation
bug 171405 Tabs management
bug 168379 Investigate possible editor tab management improvements
bug 169462 Unified navigation between editors, views and perspectives
bug 171405 sort editor tabs by absolute filenames and/or extension filenames

My take on this is that the whole logic behind editor tabs does not work well, and that editor tabs in Eclipse should work more like tabs in web browsers as long as you browse (not edit) code. See http://www.eclipse.org/platform/incubator/ui/tweaklets/index.php - it has a download for an experimental feature called "Editor Tab Tweaklet" that changes how editor tabs work.

Another suggestion that I haven't seen in this bug yet is Ctrl+F6 - it opens a list of editors sorted by most recent use - it is very similar to the Alt-Tab logic in Windows for switching between applications.

Thanks for your feedback though.
Comment 8 Boris Bokowski CLA 2009-11-17 13:07:05 EST
Remy is now responsible for watching the [EditorMgmt] component area.
Comment 9 Eclipse Webmaster CLA 2019-09-06 15:37:50 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.