Community
Participate
Working Groups
It would be nice to have back/forward actions similar to that of a web browser. Before going to a new class or method, the current position is recorded in the history list. The list can then be traversed using the back/forward actions. This should work for all commands that go to another class or method, for example like go to declaration and clicking on classes and methods in the tree.
Add my vote for it!
see news://news.eclipse.org:119/3C39BC1C.F7CA569A@o_ti.com for more info.
This is an interesting idea. Would you be willing to help implement it?
Are you talking to me or to Jesper ? Personally I'd really like to help, but I don't have the time to start digging into the sources. I'd be glad to help testing it if necessary.
*** Bug 2525 has been marked as a duplicate of this bug. ***
Add my vote. What are the chances that this feature is implemented for the next release?
Add my vote also. This is simple but extremaly helpful feature!
This is my biggest usability issue with elipse 2.0
any progress on this?
Just to make it a bit more do-able (or at least specifiable :-) I'd like to see Back-button-like functionality in the following JDT use case: I'm inspecting a method 'foo' protected void foo(ILoveEclipse whee) { Asdf g = bar(whee); Qwer t = baz(whee, bada(bing)); } I put the cursor over the 'bar' call and hit F3. 'bar' looks OK, so I'd like to be able to jump back to 'foo' in order to check the next call. Note that my memory is not so good that I will (or my concentration is too great to allow me to) remember anything about 'baz'. Also I'm too impatient to set a bookmark. S-F3 would be nice :-) Just keep track of the previous Open-on-Selection's.
*** Bug 22286 has been marked as a duplicate of this bug. ***
*** Bug 22623 has been marked as a duplicate of this bug. ***
*** Bug 22638 has been marked as a duplicate of this bug. ***
Incresing priority. Since there are many people on the CC list - do any of you want to work on this feature?
This is one my pet topics in Eclipse and I'll be happy to work on it with anyone else. I think navigation in Workbench should focus on editors. Movement to/from/inside editors is what's important. Someone on the mailing list said that ideally navigation support should sense when there is a relevant "jump" in the editors, marking where a new edit has started and adding the previous location to history. This implies a generic but heavily editor focused navigation functionality. An alternative would be to provide a workbench history and let individual plugins add new history items on their own. This has the advantage of being relatively east to implement on the Platform but requires more work from individual plugins. My previous plugin submitted to bug#12066 did this after some fashion. At this point I think the editor focused alternative may be a better fit. In any case, I think navigation in views should be left to views themselves and this bug should only worry about navigation in editors. For the editor alternative, presenting navigation context in a better way is a bigger issue since history contents would not be added directly by other plugins. There could be an extension point (or just an adapter lookup on an editor input for a navigation context) where different editors contribute mappings from simple text selections or ranges to higher level models. For example, pressing F3 in a CU editor causes a new editor to open and the class name to be selected. Then, the user clicks on a method in the outline which causes the selection the editor to change. The workbench could listen to selections from the active editor and map the previous selection (which is the class name at this point) to its actual class with all the label decorators when asked to display a history. Even though the example is a text based editor, there is nothing here that would prevent other kinds of editors from participating. Any kind of selection could be mapped, so for example PDE plugin.xml editor could provide labels for individual parts of a plugin descriptor. How does this sound?
Cagatay, I'll give you a hand with this one. Your selection-driven approach sounds like it will cover most navigation, at least for the JDT plugin, where navigation usually has an accompanying selection (F3 and the outliner). If this navigation history is going to be part of the platform (and I think it should be), we should also try to accomodate other navigation signals such as key strokes and mouse clicks which I think we can just call "cursor movements." These inputs could generate a lot of false positives - for example, if you're scrolling the editor via the keyboard, you don't want each of those cursor positions to be part of the history. We'd probably only want to add cursor movements to the history after a timeout, the timeout being indicative in the users interest in a location.
I am not sure about using a timeout. Apart from the accessibility issues it will introduce am not conviced that it would accurately reflect the users interest in a section of the file. A simpler gesture to capture would be the user begins editing at a location.
The problem with the edit approach (for me, at least) is that this feature is most useful when browsing code, not when editing. The locations I want to jump between are almost never locations I'm editing.
Now that we are going to implement this feature I would like to start using the UI team's developer mailing list. Anyone interested in participating in the development of this feature please join us on the eclipse-dev@eclipse.org mailing list.
My mistake, I cut/pasted the wrong newsgroup address. Pls use platform-ui-dev@eclipse.org
*** Bug 12066 has been marked as a duplicate of this bug. ***
Just a small comment, I think you're trying to complicate things too much. Look at IDEA, it has this feature and has implemented it perfectly. It's just a matter of recording the current file, cursor and window start location (text-wise) before navigating to another position in the same file or in another file (there should be a history for each edit window). By navigating I mean everything (!) besides normal cursor movement, for example clicking on a file, going to a declaration, going to a search result, clicking on a method, creating a new class.
The current implementation (i0917) look pretty good. The only thing i miss right now is shortcut keys for it (and i know i can do ALT-N, F or B) I don't know what i good one would be (CTRL-SHIFT-LEFT/RIGHT Arrow is not an option because that selects words) But maybe CTRL-SHIFT-B and F??
Hard to type and on different hands. How about Ctrl-[ and Ctrl-]?
Ctrl-[ and Ctrl-] is a bit clumsy on german keyboards (it's Ctrl-AltGr-8 and Ctrl-AltGr-9, with AltGr being the right Alt key)
As already mentioned there is a first cut of this functionality in the 20020917 build. What's there is only good for browsing and rather useless when editing files as the implementation does not track the changes to update the entries in the navigation history. HEAD in the dev.eclipse.org repository contains a version that tracks changes. The relation between entries in the navigation history and the perspective in which they have been recorded is still open. Do you expect the back/forward actions to also switch to the original perspective of the entry? So far we took the simplest possible approach to get things working without requesting to much cooperation from clients. This is causing trouble in special situations such as debugging. You are probably not interested in populating the navigation history when stepping through a program. This particular problem is caused by the current implementation of how the debugger reveals the execution pointer but shows the general problem. We need to understand what kind of external control over the navigation history is required. Among others, two possible control mechanisms are: a) We could provide methods for closing/opening the navigation history. It wouldn't be possible to add an entry to a closed navigation history. Taking the debugger example, the debugger would close the navigation history before revealing an execution pointer and reopen it afterwards. b) More general, we could support stackable filters which each entry that should be added to the history must pass. The debugger would add a filter that blocks all entries generated from revealing the execution pointer. Which degree of external control do you think is necessary?
kybinding: what about alt+right/left arrows just like in browsers ? I think option A above is simpler and better
I always bind it to ALT + left/right in my IDE's. Hopefully user customizable key bindings are fixed at the same time as this feature ;-)
The explicit disabling of the history seems like the most straight-forward approach for clients and the most cost-effective approach for the platform. It creates the risk of a client disabling the history and never turning it on again, but a badly written filter could do the same thing.
A usability nit. The back and forward buttons move around in the toolbar depending on the active editor (e.g. when navigating from a .java to a .class file). This makes it unpleasant to repeatedly navigate back in the navigation history with the mouse only. Having the navigation buttons appear before editor contributions would avoid this problem.
Comment suggests that Back/Forward will be so frequently used that location in the toolbar will become a usability issue. How much more important, then, to provide a convenient keyboard shortcut for these actions.
I added back/forward navigation support to my plugin just by using selectAndReveal() instead of other API. The beauty of this, to me, was that I could support a new feature while maintaining compatibility with 2.0! This is very clever! This feature seems important enought to me that I would use it as a base for a standalone product. But if it could not be exercised compatibly with 2.0 I would ignore it for a plugin product (because who can support different product versions for, e.g., build 20021005 and 20021010?). I hope this distinction will be a consideration in how the feature is extended.
I tried this feature in the 20020923 build and it didnt work correctly. The current cursor and window start position aren't saved when moving back/forward. Also when pressing F3, moving the cursor and then going back the cursor moves to the method declaration when it should move to the point where I pressed F3. These bugs are probably related.
Moving to Text to address Jesper's last note.
Has been fixed. Verified in I20030715