Difference between revisions of "Talk:History behavior"

Latest revision as of 01:45, 1 April 2007

--Ericb 17:23, 27 March 2007 (CEST): One thing that I don't like with the history mechanism in EiffelStudio and other tools is that it's not always the oldest item which is removed from the list. Let's consider that I looked at classes A, B , C, D in that order. The history will look like that:

A B C D
      ^

If I then go backwards to look at B again (using the history navigation means):

A B C D
  ^

and then decide to look at class E, then C and D will be removed from the history, even though I looked at them more recently than A:

A B E
    ^

I find this situation very annoying. In a tool that I wrote, I implemented a history mechanism where only the items to the left of the history (i.e. the oldest) are removed. It is probably not a standard behavior, but I find it more convenient. It works as follow. Let's consider that I have:

A B C D
  ^

and want to look at class E, then my history will look like that:

A C D B E
        ^

B has been moved forward because that's the class I was just looking at, and then E has been added. That way I don't lose C and D, they are still in the history, still accessible using the history navigation means. Likewise, if I then drop class C in my tool, the history will look like that:

A D B E C
        ^

I find it more convenient than:

A C D B E
  ^

because C is really the most recent class that I looked at.

--manus 22:56, 27 March 2007 (CEST) EiffelBench implemented something like that, but we dropped it partly because it was confusing. Moreover the fact it is not standard behavior might not be a positive point for certain people. However something we could do is preserving the back and forth button behavior (i.e. acting the same way as in your web browser) and changing the dropdown to list the most recently used items first and then the history (the way it is done in some of Microsoft tools for style/font selection). What do you think?

--Ericb 00:39, 28 March 2007 (CEST): Do whatever you want, but don't throw away recent items before older ones. I must say that I really like the way the history works in my tool (as described above), despite not being standard. It is very convenient and I don't find it confusing at all. To the contrary, it is less confusing than having items disappearing from the history just because I clicked a couple of times in the back button before dropping a new class. This behavior is not acceptable to me. It's not a question of confusing or not, but of acceptable or not. I don't think that history should work like a undo/redo mechanism. But the impression that I get from EiffelStudio's history is exactly that: a undo/redo mechanism, not redone actions are lost when executing a new action.

--Ted 04:42, 28 March 2007 (CEST): I don't like the way items are thrown away neither, so I had an idea I called it Insertion mechanism. As long as one think it the way editing the text at inserting mode, it is easy to understand. It works like this:

A B C D
  ^
A B E C D
    ^

Time items are inserted or visited is also tracked, and the oldest one will be removed when a new item is inserted. I know that this mechanism also breaks the standard way. By any means, not throwing away recent items is contradictory to the standard behavior, because the standard does. The reason I don't like Eric's is that moving items around is really confusing, at least for me, and I would rather keep it as what it is.

-- larryl 05:09, 28 March 2007 (CEST) Visual Studio 2005 has the same history behavior as the last behavior Ted described. I think that one it the best one so far.

--Ericb 11:20, 28 March 2007 (CEST): Sorry, I still prefer the behavior I described. The behavior described by Ted is not satisfactory to me because E is more recent than C and D, so it should appear to the right of these two classes. Otherwise E will be removed (at some point) from the history before C and D, even though it is more recent. The behavior that I described is not something that I came up with one morning when waking up. I gave it a lot of thoughts. It is the result of several trials and corresponds to what is the more useful for me in practice, while not that confusing after all (at least not for me) compared to other solutions.

--Ted 11:48, 28 March 2007 (CEST): E will not be removed before C and D. I said the time E inserted is tracked, so the structure in fact does not anymore fully represent a sequence in time.

--Ericb 14:27, 28 March 2007 (CEST): If you don't call this behavior "confusing", what do you call it?

--Paulb 20:02, 28 March 2007 (CEST) Okay, so here it is. The Visual Studio mechanism works very well but the issue with Visual Studio is that it does not have a real history. Visual Studio navigates documents using CTRL+TAB, which we have in EiffelStudio. In Visual Studio it is very effective and behaves in a similar manner to what Eric is describing. In addition you cannot open a previous opened and closed document, like you can with the EiffelStudio history.

To explain the process you need to consider that an open document cannot have it contents replaced by another document, as with EiffelStudio. Opening a file will always create a new tab (I wish ES could be configured this way, as do others)

For the initial open documents, start with A through D. D will be the last opened.

A B C D

Using CTRL+TAB to access the history an select B would yield a history

A C D B

B is moved from it previous position an placed at the end. This would also be true if you attempted to reopen B. It's logical that D was used prior to B so hitting CTRL+TAB once would flip back to D.

A C B D

If the user wants to got two steps back they'll press CTRL+TAB, release TAB and press TAB again. Pressing TAB twice (same as ALT+TAB in Windows.) would end up with C as it's two positions back.

A B D C

You see C is now at the end next to D, which was opened last.

If A is then closed the history is as such

B D C

A no longer belongs to it. As I said, this is not a real history.

END OF VS METHOD DESCRIPTION.

Using the VS mechanism in EiffelStudio, using the back and forth buttons, you would only be able to switch between the two last opened documents. This is because Vs maintains a most recently used list and not a history. Every time a document is visited it's placed at the end of the "history", as described above. This can be remedied by using a cursor as Eric described in his approach of using a cursor. That is:

A B C D
      ^

Press back twice

A B C D
  ^

Press forward once

A B C D
    ^

What happens when you open a new document now? Current described rules, by others in this discussion, dictate that it should appear after D. I say no. When you navigate back in a history, any new changes at that point wipe out the future. That is to say:

A B C D
    ^

Now we open E

A B C E
      ^

D is wiped out, just like undo/redo. Eric approach although effective to himself because he knows the internals, will actually be confusing to those that don't. The same holds true for Ted method of insertion.

Neither approach works on their own. There are two approaches we can take. One with the current mechanism of being able to swap documents or the other without swapping. Without swapping is much easier to implement.

You need to maintain three separate histories. You need an open/viewed document history that monitors what tabs are opened and switched to, I'm calling the Open History (OH). This would behave in exactly the same manner as Visual Studio, as described above. The other history is implemented using a cursor and works for the back and forth buttons, I'm calling the Visit History (VH). The difference between OH and VH is that VH maintains items that have closed as well as hosting similar history items. In addition VH will track both switching of classes and features. The thrid and final history I'm calling the Recently Used History (RH), for the history combo box. RH is like OH but maintains closed items.

To exampling, let's start with A through D again.

(OH) A B C D
(VH) A B C D
           ^
(RH) A B C D

Press back once

(OH) A B D C
(VH) A B C D
         ^
(RH) A B D C

C is move in OH and RH and placed at the end.

Press back once again

(OH) A D C B
(VH) A B C D
       ^
(RH) A D C B

B is move in OH and RH and placed at the end, after the last viewed C.

Press forward

(OH) A D B C
(VH) A B C D
         ^
(RH) A D B C

C is move in OH and RH and placed at the end, after the last viewed B.

Close A, without switching to it using the X on the tab.

(OH) D B C
(VH) A B C D
         ^
(RH) A D B C

A is removed from OH because it only maintains the history for opened items. All other histories are unaffected.

Now using CTRL+TAB switch to B.

(OH) D C B
(VH) A B C B
           ^
(RH) A D C B

You see that B now appears twice in the VH. D has also been removed from VH because changing the past events affect the future. Always note that OH and RH switched to class at the right most of the history.

Now open a new class E

(OH) D C B E
(VH) A B C B E
             ^
(RH) A D C B E

Now this history is outlined the semantics of VH and RH need to discussed with respects to the multi-tabs editor. Currently EiffelStudio supports swapping open document tabs with different content. I also propose that we have a preference that is strict in a tab-per-document, i.e. not swapping permitted.

1. With swapping:

Now we have multiple tabs maybe the VH back and forth history should only pertain to the active tab, just like multiple-tabbed web browsers. An issue is that you could navigate back in a tabs history to open the same document that is already opened in another tab, which should not really be permitted. There are three solutions to this

• When reaching that history item, switch to the opened tab. However with localized tab history what's the consequence of switching to a new tab? Does the switched to tab history take over? It shouldn't because that's not the history the user was navigating through. That would be the only viable option unless you really want to mess up the history trying to do overly complex tracking.
• Skip or remove the history item if it's open in another tab. But this creates an incomplete history.
• Prompt the user to switch to the open tab. This is going to get annoying because what if there are other history items that you have to navigate past, that have their documents open in other tabs. You would be prompted for each one!

So, in my mind, there is no nice solution.

I discussed this with Julian and Martin and the only solution visaged would be to allow the same document to be opened in the editor. Martin actually wants this behavior because there is no way to edit the same document in two places using a vertical split editor, like most editors have. Allowing the same documents open multiple will enable this. However the multiple tab editor will need to be modified to abstract the view from the underlying buffer, so modifications are synchronized between the views.

For the RH, selecting an item would either switch to an already open document or replace the current tab with the selected unopened document.

2. Without swapping:

Without the ability to swap documents the VH back and forth buttons would act globally. That is switching to any opened tab that hosts the history item or opens a new tab if the history item is associated with a closed document.

The rules for RH are the same as using the VH.

--neallester

I don't have time right now to read or join the conversation, but I found this analysis of web browser navigation interesting.

--Ted 04:34, 29 March 2007 (CEST) Swapping or not doesn't really matter to me when I am using VH. What I am interested in is the text displayed in front of me is the one I needed, no matter how the tool handles it. I didn't know how VS worked until Larry posted, and I tested in VS, I found this described by Paul is suspicious:

What happens when you open a new document now. Current described rules dictate that it should appear after D. I say no. When you navigate back in a history and new changes at that point wipe out the future. That is to say:

A B C D
    ^

A B C E
      ^

D is wiped out, just like undo/redo.

The result should be:

A B C E D
      ^

And I also found that VS also takes cursor positions as history records. Once a tab is closed, all that page related history records are removed. All above I am talking about is VH.

--Paulb 18:44, 29 March 2007 (CEST) Ted, I need to make it clear that VS does not actually have a VH it only has a OH. In fact the OH is just a Most Recently Used mechanism and is not a history mechanism at all. There is no history cursor! There is no way to navigate back and forth in VS! What you find suspicious does not relate to the quotation of my previous entry. I think this is a confusion brought about on my part. I did not separate the sections correctly. I've just revised them.

As a side note, Eclipse supports a real history but do not allow documents to be swapped.

-- larryl 04:06, 30 March 2007 (CEST) I have made two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS. I have sent the videos to Paul's email.

--Peter gummer 11:45, 1 April 2007 (CEST) Regarding the discussion about Ctrl+Tab in VS, I'd like to point out that this was the thing that annoyed me most about VS 2002 and VS 2003. My brain does not maintain a stack of files that I have been working on. The way Ctrl+Tab worked in VS 2002 and 2003, it might as well have been switching to a random file: sometimes I can't even remember the last file that I looked at, never mind the second last. Even after using VS every day for two years it still irritated me. VS 2005 has improved this by giving me visual feedback of where it's about to switch to, and I'm very pleased that EiffelStudio has adopted this approach. My preference, however, would be for Ctrl+Tab simply to switch to the next tab to the right, like the Windows "Display Properties": Delphi always worked like this, and I always found it extremely easy to use: I didn't have to waste my limited brain space trying to guess where Ctrl+Tab would take me, because the tabs were there right in front of my eyes.

But is Ctrl+Tab really relevant to this history behaviour? Paul wrote above that VS has no history cursor. But it does, and it's one of my favourite features in VS! Hit Ctrl+Minus: VS takes you to the last place the cursor was. Then hit Ctrl+Shift+Minus: VS returns you to where you were before. This is very close to what we are discussing here.

By the way, one thing that's always annoyed me about Alt+Left and Alt+Right in EiffelStudio is that it does not remember cursor movements. I usually move around a class text by Page Up or Page Down, etc. It's really irritating to hit Alt+Left, only to be taken to the top of the class text rather than to where I was.