Suggestions for changed in behavior for next/previous

[ideasman42]

From reddit user nv-elisp.

---

Pretty cool. I find the graph easier to follow horizontally than the vertical orientation undo-tree has.

A few ideas/suggestions:

I would expect vundo-next to work here as well and follow the diagonal of the graph. From here:

o--x--o
   `--o  

to here:

o--o--o
   `--x  

And I would expect vundo-previous to work similarly:

o--o--o
   `--x  

would lead to here:

o--x--o
   `--o  

Basically follow the lines of the graph when pressed instead of hopping to the the parallel point in the graph. This was just my initial impression, though. I could see getting used to the way it currently works as well.

It would be neat if one could click on any of the unselected points in the graph and show a buffer diffing current position in the graph with that point.

Another idea is to record/display some information about each point in the graph when navigating. Perhaps the time the edit was made?

Food for thought.

[casouri]

I don't have a clear mind on this, because when there are more than two branches, it is not obvious that the proposed semantic is more intuitive than the current one.

Basically follow the lines of the graph when pressed instead of hopping to the the parallel point in the graph.

"Following the lines of the graph" becomes ambiguous when you have more than two branches at a single node, IMO.

It would be neat if one could click on any of the unselected points in the graph and show a buffer diffing current position in the graph with that point.

Another idea is to record/display some information about each point in the graph when navigating. Perhaps the time the edit was made?

These are nice, but I don't think they are that useful to justify implementing. TBH, I only use vundo from time to time, when undo-only and undo-redo doesn't cut it.

[ideasman42]

Okay, feel free to close this report if you don't think it's practical to implement. (also only use vundo from time to time).

[noctuid]

Two users in that thread tried to go down in this situation and were surprised it didn't work. I felt the same way when I first tried vundo.

Is this the situation you describe?

○──○──○──x──○
           │──○
           │──○
           └──○

I'd expect this still:

○──○──○──○──○
           │──x
           │──○
           └──○

[casouri]

Consider this tree, when I press n, should the cursor move to A or B?

○──○──○──x──○
      │  └──A
      │──B
      └──○

Of course, we can make it that if the current node doesn't have a sibling, n moves to its second child. But that could be more confusing. It might be better to learn one rule and have it consistently applied everywhere, ie, no special cases.

[noctuid]

I would expect to go to A and not to B there. Intuitively for me, I would expect to have to go back to the root and then go down. I'm not really sure what is best though. I've never used a horizontal tree like this before.

It might be better to learn one rule and have it consistently applied everywhere, ie, no special cases.

Yes, probably. The current behavior seems the most consistent. I can get used to it.

[progfolio]

If the argument is one of semantics "next" and "prev" aren't really great names for the commands for the same reason. If we are at a branching point, what does "next" mean? I think better names for the commands would be something like "forward", "back", "up", and "down" unless you plan on allowing the graph to be displayed in a different orientation in the future. Just food for thought.

[OlMon]

I just want to through an other idea in the mix. This is the current display style:

o--o--o
   `--x  

Change it to:

o--o--+--o
      `--x  

This moves the parent knot one step to the left and the "+" sign just displays, that there is a split. The movement would be the same, but maybe more intuitive. Start:

o--x--+--o
      `--o  

Press "f":

o--o--+--x
      `--o  

Press "n":

o--o--+--o
      `--x  

It is just an idea for the discussion.

Cheers!

[casouri]

Thanks for your thoughts on this. Still waiting for a brilliant solution that solves all of our problems ;-)

I thought more about the original proposal and found this issue:

o--A--o
|--B--o
|  `--D
`--C

In such a tree and according to the proposal, pressing n brings you to B, and press n again brings you to D. However, there is no way to get to C.

[walseb]

I apologize if this has already been said but the way visual undo tree does this is through having switch branch (n and p in this case) just change which branch is highlighted. Redoing (going right or pressing f in this case) simply traverses forward in the direction of the highlighted branch. I haven't considered all the trade-offs so I don't know which I prefer. I just thought it was worth mentioning as I didn't see anyone mentioning it during my speed reading of the thread.

[casouri]

Thanks for chiming in. For the record I have thought about the way undo-tree does it. But it is not easy to implement in vundo due to how we move between nodes and how is the tree drawn.

[jdtsmith]

One trivial idea I had on this old topic: at the branch point (yellow below), n/<down> do not do anything. I think it would make sense for them to descend to the root of the next child (lower green node). For <down> especially this would be sensible to "flow along the line". This behavior is also available on the next node (first child), but I don't think that would lead to any confusion.

[michael-heerdegen]

Good to see that you are still thinking about this problem. A lot of users may come from undo-tree, and it is really hard to get used to the alternative behavior of vundo. Which I didn't like much, btw, but I'm still used to it.

Maybe consider to just implement an option that when turned on "does what has been suggested above when the situation is not ambiguous, else just raises a user-error." That would not be hard to do and still satisfy most users (without having thought too much about this).

[jdtsmith]

@casouri any thoughts on attaching <down> behavior at a branching parent node?

[michael-heerdegen]

JD Smith @.***> writes:

@casouri any thoughts on attaching behavior at a branching parent node?

Do you mean "do the same thing as undo-tree does: just select branches without changing the current node"?