NEW DATE! Bugzilla will undergo maintenance 2024-03-28 18h00 CET. Bugzilla will be placed in read-only mode at that time.

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 5700 - Back/forward actions
Summary: Back/forward actions
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 2.0   Edit
Hardware: PC other
: P2 enhancement (vote)
Target Milestone: 3.0 M2   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 2525 12066 22286 22623 22638 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-11-09 05:13 EST by Jesper Nordenberg CLA
Modified: 2003-07-16 07:14 EDT (History)
24 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesper Nordenberg CLA 2001-11-09 05:13:31 EST
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.
Comment 1 Genady Beryozkin CLA 2002-01-11 08:24:49 EST
Add my vote for it!
Comment 2 Genady Beryozkin CLA 2002-01-11 08:28:09 EST
see news://news.eclipse.org:119/3C39BC1C.F7CA569A@o_ti.com
for more info.
Comment 3 Kevin Haaland CLA 2002-01-24 21:26:22 EST
This is an interesting idea. Would you be willing to help implement it?
Comment 4 Genady Beryozkin CLA 2002-01-25 12:01:51 EST
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.
Comment 5 Nick Edgar CLA 2002-03-06 17:18:00 EST
*** Bug 2525 has been marked as a duplicate of this bug. ***
Comment 6 Zohar Amir CLA 2002-03-07 02:53:45 EST
Add my vote.
What are the chances that this feature is implemented for the next release?
Comment 7 Jarek Borelowski CLA 2002-03-22 06:29:19 EST
Add my  vote also.
This is simple but extremaly helpful feature!
Comment 8 Brian Hanson CLA 2002-03-22 09:12:10 EST
This is my biggest usability issue with elipse 2.0
Comment 9 Zohar Amir CLA 2002-03-24 02:00:20 EST
any progress on this?
Comment 10 Tom Roche CLA 2002-07-28 15:02:11 EDT
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.
Comment 11 John Arthorne CLA 2002-08-19 16:34:52 EDT
*** Bug 22286 has been marked as a duplicate of this bug. ***
Comment 12 Simon Arsenault CLA 2002-08-23 11:52:50 EDT
*** Bug 22623 has been marked as a duplicate of this bug. ***
Comment 13 Simon Arsenault CLA 2002-08-23 11:55:30 EDT
*** Bug 22638 has been marked as a duplicate of this bug. ***
Comment 14 Kevin Haaland CLA 2002-09-05 13:15:45 EDT
Incresing priority. 

Since there are many people on the CC list - do any of you want to work on this 
feature?
Comment 15 Cagatay Kavukcuoglu CLA 2002-09-05 14:11:29 EDT
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?
Comment 16 Jared Burns CLA 2002-09-06 11:22:36 EDT
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.
Comment 17 Kevin Haaland CLA 2002-09-09 14:49:50 EDT
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. 

Comment 18 Jared Burns CLA 2002-09-09 15:12:22 EDT
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.
Comment 19 Kevin Haaland CLA 2002-09-09 16:22:58 EDT
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. 
Comment 20 Kevin Haaland CLA 2002-09-09 16:28:56 EDT
My mistake, I cut/pasted the wrong newsgroup address. Pls use

 platform-ui-dev@eclipse.org
Comment 21 Eduardo Pereira CLA 2002-09-09 17:03:48 EDT
*** Bug 12066 has been marked as a duplicate of this bug. ***
Comment 22 Jesper Nordenberg CLA 2002-09-10 03:04:02 EDT
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.
Comment 23 Johan Compagner CLA 2002-09-18 18:26:17 EDT
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??
Comment 24 Bob Foster CLA 2002-09-18 19:46:36 EDT
Hard to type and on different hands. How about Ctrl-[ and Ctrl-]?
Comment 25 Jörg von Frantzius CLA 2002-09-19 04:16:21 EDT
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)
Comment 26 Kai-Uwe Maetzel CLA 2002-09-19 05:06:52 EDT
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?
Comment 27 Genady Beryozkin CLA 2002-09-19 14:24:41 EDT
kybinding: what about alt+right/left arrows just like in browsers ?
I think option A above is simpler and better
Comment 28 Jesper Nordenberg CLA 2002-09-20 09:21:07 EDT
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 ;-)
Comment 29 Jared Burns CLA 2002-09-21 17:58:45 EDT
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.
Comment 30 Erich Gamma CLA 2002-09-23 03:50:08 EDT
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 31 Bob Foster CLA 2002-09-23 23:47:59 EDT
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.
Comment 32 Bob Foster CLA 2002-09-24 00:15:40 EDT
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.
Comment 33 Jesper Nordenberg CLA 2002-09-24 03:52:34 EDT
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.
Comment 34 Nick Edgar CLA 2002-10-22 13:24:49 EDT
Moving to Text to address Jesper's last note.
Comment 35 Dani Megert CLA 2003-07-16 07:14:03 EDT
Has been fixed.
Verified in I20030715