Open mentalisttraceur opened 9 months ago
Glad you like vundo-diff. I find it's especially useful with the new l
/r
saved node navigation and marking.
Vundo does not work like undo-tree in terms of selecting branches. You always move left/right on the "top-most" branch, unless you explicitly move down to a sibling at the base of a branch. Since you can already navigate without moving upwards through all branches, it would be hard to record the "current" path you took through the tree even in principle.
I suppose one could mark any branch containing nodes which have most recently been visited as current (among its siblings) and, style that zig-zagging path. Then provide alternate navigation commands that moves up/down the current path. If no branch has been visited, the "topmost" rule would hold. We already use bold connector lines to indicate true branch points (because sometimes the same branch has to "bend down" to find room to continue). But color could be possible. Something like this would put extra load on the re-draw, because it would happen (in principle) on every movement. Right now drawing happens once, and overlays are moved to indicate node position. If we sped up draw (showing only the data needed + a buffer around it, for example), this would probably be fine.
You can use a
/e
to move to the base or tip of a given branch, btw.
For what it's worth, so far I find myself wanting the functionality more than the visual. Even if there's no visual indication of the "current"/most-recently-visited branch (and thus, I hope, zero cost w.r.t draw), just having the motion commands would've already helped me on at least one occasion since I've switched from undo-tree to vundo.
Feels like it would be quite confusing if it hops to a random branch when descending, without any visual indication. Let's see what @casouri thinks.
If the only issue is user confusion, maybe just don't give any out-of-the-box keybinds for it?
People like me would go out of our way to
describe-function
, andSuch users already find this behavior intuitive and are proactively looking for it.
I could probably also implement this from the outside with some wrappers, but the stuff I'd need to get started is marked private.
Namely, I think I'd need one of vundo--stem-{end,root}-p
and a function to get the current node.vundo--current-node
It wouldn't be hard to put together a PR to gauge interest. The main things needed:
vundo-m
struct like vundo-m-active-child
which is updated in the parent with the child connecting it to a given node, when that node gets visited. vundo-forward
to use this "active child" instead of the first child ((car (vundo-m-children this))
).Cheers! I appreciate the tips. Not sure when/if I'll get around to it. For now I'm just jotting down thoughts as a prospective user while I try switching from undo-tree to vundo.
Unfortunately, one possible indefinite delay is that sometime after my last comment, I tentatively decided to switch back to undo-tree, for unrelated reasons.
One UX nicety of undo-tree is that if you hit back to a branch point, and then hit forward, you go forward in whatever branch you were just on.
undo-tree visualizes this by coloring the currently "selected" branch slightly differently.
Is it feasible/realistic to have that in vundo?
Currently, as a user used to undo-tree, this feels like a big efficiency loss, because I am so used to being able to toggle between any two adjacent nodes by just hitting by back/forward keys (my thinking and muscle memory doesn't have to be predicated on whether or not I'm just in front of a branch boundary).
However, as I get used to vundo's capabilities, I may stop wanting this:
So I'm not advocating for this to have high priority. But it seems like a nicety worth adding if it's fairly easy.