Community
Participate
Working Groups
The current means of editor management - the scrollable arrow keys next to the editor tabs and the ctrl+f6 pop-up - are insufficient. Both of these mechanisms require the user to perform on the order of N operations to switch editors, where N is the number of open editors. To alleviate the problem, I propose the creation of an "Editor view" which displays a flat list of the open editors. Single-clicking an editor in the editor view would activate the selected editor. I believe this would require the user to perform a constant number of operations (1 or 2) to switch editors.
This has come up before and is a very good idea. It's unlikely that we will be able to implement this enhancement for the 2.0 release.
If this is considered an approved feature (that is, it will be added to the repository if implemented), I'll take a look at this if I find some spare time.
I've done a preliminary implementation of an "EditorList" view. It does the basics - displays the currently opened editors and activates editors when selected. To make this feature *really* useful, I'm going to explore adding the notion of working sets. I would personally find it handy to be able to define sets of editors to display when I'm working on a particular problem. For example, I'd like to define a "breakpoints" set that would open editors on the breakpoint hierarchy.
I have a very rough cut of working sets working. For now, I just copied and modified the Search Working Sets to work in the Platform UI and used that. I'll use the official working set support (Bug 11044) when it is completed. I've also added "sort by name" functionality and forward and back history navigation.
Jared, This is great news. As soon as you feel it is ready to be tried by other Eclipse UI developers please create an attachment to this PR and let us know on the UI team developer mailing list.
Created attachment 513
Created attachment 514
Created two attachments. editorlist.tar.gz - Contains the editorlist package. This file should be decompressed and the resulting directory ("editorlist") copied into the org/eclipse/ui/views directory of the org.eclipse.ui project icons.tar.gz - Contains two icons used by the EditorList. editor_list.gif, which is the icon used on the view's title bar, should be copied into org.eclipse.ui/icons/full/cview16. editor_workingset.gif, which is the icon used for the working set action on the view's toolbar, should be copied into org.eclipse.ui/icons/full/clcl16. org.eclipse.ui/plugin.xml needs to be manually tweaked to enable this view. Under the org.eclipse.ui.views extension area, add: <view id="org.eclipse.ui.views.EditorList" name="%Views.EditorList" category="org.eclipse.ui" class="org.eclipse.ui.views.editorlist.EditorList" icon="icons/full/cview16/editor_list.gif"> </view>Finally, add the following to org.eclipse.ui/plugin.properties: Views.EditorList = Editors
It would be good to avoid duplicate functionality with the Switch to Editor dialog. Ideally, the same functionality could be opened either as a view, or just on demand as a dialog. (Note that a competing product allows dialogs to be docked as views). We're planning on adding some extra management actions to the Switch to Editor dialog. Also, it would be good to support drag and drop to add to working sets if you don't already.
I've migrated the working set support to the official support that is being worked on in Bug 11044. It appears to work well, though there are some issues around the fact that the platform working set support allows projects and folders to be added to working sets. It *could* be useful to specify a folder; for instance, I might specify my "breakpoints" working set by selecting the breakpoints package. The question that follows is whether or not to traverse the directory structure. Opening all files in selected folders recursively could cause a real mess. Then again, we might just want to say that if a user adds a project to a working set and then chooses to open that working set, they'll get what they asked for.
As a first pass, I think I'll traverse the directory structure in the background to determine how many files are available to be opened. If the number is greater than some threshold (20?), I can pop up a dialog (where N is the number of files found): Message: This working set contains N files. Do you really want to open all files? Buttons: Yes | No
Is there anything I can do to help for this bug?
Created attachment 714
I've made a plugin out of this so that it can be easily dropped into an Eclipse install and tested. There is a problem with Bugzilla such that it will try to save the file as "showattachment.cgi" The attached file should be saved as "EditorList.zip" For now, the working set support is extremely lightweight. It will only open files which are explicitly defined in the working set and it won't give any errors if your working set does not contain any files. If the editor sets are considered useful, I'll polish the support up to production quality.
Note that the view listed as "Editors" under "Basic" with the navigator and such.
The latest attachment doesn't download properly, all I can get is a file 154 bytes long, probably truncated.
Created attachment 715
Created attachment 716
Please grab the latest EditorList.zip (20020426). My original zip was corrupted. Joe was kind enough to zip up the contents for me, but his archive ("New EditorList.zip") doesn't have the correct directory structure (it lacks the enclosing folder). To install this plugin, unzip the latest EditorList.zip and drop the resultant directory ("EditorList") into the plugins directory of your Eclipse install. This version should be compatible with the last two stable builds and all integration builds in between. Sorry about the mess. The attachments are small and I hope to have the Bugzilla maintainers delete the old ones soon.
Created attachment 1865
Enhancement request: If the editor list is not sorted alphabetically, order the list so it matches the editors left-to-right. It is possible to move an editor tab, and it would be nice if the editor list updated as editor tabs were moved. Barring this, a 'refresh' button would be nice.
Added the ability to create working sets from the EditorList view. I've found this is useful when I'm working on one problem and decide to go work on another for a bit, but I want to "save my place" in the original context. You can now multiselect editors in the view, right click and choose "Create Working Set" to create a working set that contains the selected files.
The editor list shows error icon overlays, but when the errors are fixed, the error overlays don't disappear from the editor list.
Created attachment 1874 [details] EditorList.zip version 20020822
This latest version adds a menu item to "Refresh" the view. This allows users to work around any problems that still exist with updating. Also, opened Bug 22722 "Editor references not returned in tab order." If this bug is addressed, the Joe's enhancement request (displaying the editors in the tab order) will just work.
Created attachment 1886 [details] EditorList.zip - Version 20020823
The latest version fixes the bug with error markers not being updated correctly. The image in the view now correctly mirrors the image on the editor tab. Added ALT+LEFT/RIGHT history navigation to the view. Supported hotkeys now: DELETE - Close selected editors F5 - Refresh view contents ALT+LEFT - Previous editor ALT+RIGHT - Next editor
Opened Bug 23032 requesting that the UI's editor reference implementation support the IAdaptable interface. If this change is made, the editor view will support the Team menu. I've already got this working in my workspace where I made the necessary change to the UI for testing.
Like it, use it every day now. Thank you. Enhancement request: I've played with using the view as a fast view. Idea was to click, find editor, and then double-click; the view would return to the fast view icon mode and the editor would have focus. View does not minimized back to an icon when in fast view mode. Thanks again.
+1 to Pat's suggestion.
I've implemented the double-click behavior. Unfortunately, I can't share the latest code until my patch to Bug 23032 is checked into CVS. Hopefully, this can happen for the 20020910 integration build.
Created attachment 1954 [details] EditorList.zip - Version 20020909
This version contains the double-click behavior and the Team menu support. The Team menu support will not work without the IAdaptable change requested in Bug 23032. Until that bug is resolved, I've added a simple defense so that the code will work with or without the IAdaptable patch. This version also contains a workaround to a UI problem whereby some key notifications (DEL, F5, etc.) aren't being sent on keyPressed. The workaround is to perform these actions on keyRelease.
Created attachment 1956 [details] EditorList.zip - Version 20020909a
Version 20020909 contained a bug I introduced in a refactoring (doh!). The problem was that the history wasn't properly initialized if the view was created with no editors open in the workbench. This resulted in an NPE when an editor was opened and the view tried to add it to the uninitialized history. The problem is fixed in Version 20020909a.
In the interest of convenience, I've made a SourceForge project to host this plug-in. Future development (bug reports, discussions, releases) will happen there. The URL is: http://www.sourceforge.net/projects/editorlist/
There are no plans for the UI team to work on this defect for 2.1. Reasign to inbox.
*** Bug 15928 has been marked as a duplicate of this bug. ***
*** Bug 15431 has been marked as a duplicate of this bug. ***
Is this still being worked on as an Eclipse view, or is the sf plugin where it's going to stay?
I hope this will eventually be included in Eclipse, but it is starting to look more pessimistic for 3.1.
Not for 3.1
(In reply to comment #42) > Not for 3.1 Hmmm... this is bad news :-( Would it be possible to know the reason(s) why the implementation of this view is postponed and postponed again since 2002 !? Isn't it an interesting feature ??
It is interesting, but it is not a plan item and so can only really be done if time permits. While I (as a lowly committer) can suggest plan items, it is ultimately the PMC that decides what stuff is truly important. As the look of editors were changed during the 3.0 cycle, it doesn't seem important to devote a lot of time to changing them again during 3.1. Perhaps we will be able to look at this again sometime after 3.1.... And, just so you don't feel completely neglected, Platform/UI (a team of six full-time committers) currently has 3064 open bugs. Many wonderful things don't get implemented just because of the load. :(
*** Bug 63802 has been marked as a duplicate of this bug. ***
Bug 63802 is not exactly a duplicate of this bug because i was talking about http://editorviewer.sourceforge.net plugin. I tried both, editorlist and editorviewer and i found the latter much more useful because it can show the edited files in the exact project directory context where they live. Please consider editorviewer fatures for inclusion in eclipse.
*** Bug 132707 has been marked as a duplicate of this bug. ***
Moving Dougs bugs
Does anyone feel this feature is still necessary given the improvements made to the ctrl-e dialog?
The ctrl+e dialog is nice and may be a valid alternative... But - have you tried creating two stacks of editors and using that dialog? I sometimes make one editor stack where I edit and another where I read. Or I stack plugin.xml files in one area and java code in the other. Only one stack is shown with Ctrl+e. I tried hitting ctrl+e twice thinking it would bump up to a full list of open editors... no joy. Ctrl+F6 shows them all, but does not have the typing filter.... Just an observation. The function available in Ctrl+E and/or Ctrl+F6 seems to work fine when you have only one editor stack and hints that this view is not as useful now. My external thought.
Pat: have you tried ctrl-e in the 3.3 stream? It shows editors from all stacks... (as well as buckets of other functionality)
re ctrl-e, nope - still using 3.2.1+.... :-) Then I'll love 3.3!
Well, i didn't see yet 3.3 but if: - we can force the dialog to become a view so that it can be left opened - the view can show the opened editors in the folder/package context where the edited resource lives, so that with 15/20 opened editors, expecially when working on branches of the same project, where resources name are the same, we can stop hunting for the right editor.. we do not need any longer this feature. I switched to eclipse after using jbuilder and netbeans, and i'd never go back to them, but if i can point out a single drawback that sometimes makes me hate it, it is the editor management point (read MRU stuff...) Until there's a switch that allows to toggle MRU tab management so that ALL the editor tabs can be visible on multiple rows MAINTAINING their relative places IMO the only way to avoid hunting for editors is to have a view that shows the edited resource context.
By those criteria we're not yet there. Passing to Boris.
(In reply to comment #51) > Pat: have you tried ctrl-e in the 3.3 stream? It shows editors from all > stacks... (as well as buckets of other functionality) > I use Europa but CTRL-e shows only editors in current stack. CTRL-E, E doesn't show editors from all editor stacks. CTRL-SHIFT-e show a dialog with all editors, but unfortunately it doesn't support filtering.
Remy is now responsible for watching the [EditorMgmt] component area.
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.
