Community
Participate
Working Groups
I've started using Eclipse to edit Javascript and other files. One of the most annoying problems in 3.2 is the inconsistent behaviour of Editors as they embed in the IDE. Sometimes you can right click on a editor and use ShowIn; sometimes not. I'm sure it makes perfect sense to someone, but for users it is frustrating and confusing. The function of Showin is not perspective or file type dependent. It only depends upon a file and its context (the ShowIn target). Having every editor always have Showin would make navigation in a complex system much better in my opinion.
Bug 114864 made 'context menu > Show In' available in all editors inheriting from AbstractDecoratedTextEditor. Please file separate bugs for individual editors where this item is still missing.
Let me try again to explain the problem. Having global behavior defined by context-dependent code is exactly the source of the current endemic problem with eclipse UI. The eclipse IDE UI model operates on two levels: global similarity across all tools and local context tool-dependence. Globally we always have editors and views, toolbars, menus, and status bars. Locally the individual tools have logic particular to their language or task. This combination of constraints and freedoms have worked very well. Even though the constraints sometimes limit the design space for plugin, the overall trade-off for users is good. Unfortunately there is a glaring hole the model: context menus (right click) have no global constraints. Only luck or peer pressure helps users get some consistency. All I am suggesting is that Eclipse context menu have some entries that integrate all views and editors with the existing global constraints of the IDE. Concretely, items like "show-in" tie local plugin editors to the global design of eclipse: these should be inherited by all plugins and only omitted from context menus for strong reasons of editor/view design. I hope this is clearer. John.
So you want a list like we have in Open With?
(In reply to comment #3) > So you want a list like we have in Open With? > Yes, but of course its reversed: Open With is from view to editor and Show In is from editor to views.
FWIW, I really missed "Show In" while working on the documentation - it is not supported by the web browser "editor".
Implementation-wise, I think John want to see the 'Show In' menu as an object contribution on ResourceMappings (similar to 'Team', 'Compare With', etc., but in the "group.open" or "group.show" section), and not contributed by individual editors / views as it is done today. This would not entail any functional change for the user of existing SDK editors, but make sure 'Show In' is available in all editors.
The general issue identified of more consistent navigation support out of an editor could be part of a 4.0 discussion.
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.
