[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ELPA] propose to add vundo.el to ELPA
From: |
Yuan Fu |
Subject: |
Re: [ELPA] propose to add vundo.el to ELPA |
Date: |
Thu, 7 Apr 2022 17:43:17 -0700 |
>
> Ok, 3 little more:
>
Thanks, merged.
>
> Some more ideas/thoughts:
>
> (1) If you use `vundo' for the first time in a buffer with an already
> very large undo list, do you expect a delay? Would it make sense to
> limit the processing of `buffer-undo-list' to the last N entries to
> avoid such a delay (N would probably be a user option)?
That depends on exactly how large the undo list is. For any daily workload
vundo is pretty fast. For super long undo lists there is a delay but not too
bad. I just tried 1k and 10k entries, 1k took ~0.3s, 10k took ~3s.
>
> (2) I wonder which setup I will prefer in the future. I'm using the
> commands that already "fold" the undo list (AFAIU, in the same or a
> similar sense as vundo does): `undo-only' and `undo-redo'. Do these
> commands directly correspond to hitting right and left in the vundo
> buffer?
Pretty much. They don’t run the same code but the semantics should be the same.
I use undo-only and undo-redo myself.
>
> If yes, I think it would be cool to setup stuff that the keys I use for
> `undo-only' and `undo-redo' would work like now but additionally start
> vundo. And the same keys would still work in vundo and call
> vundo-backward and vundo-forwar, additionally to the existing bindings.
> I think that could feel convenient. Would such a setup make sense to
> you?
I never feel the need to see the undo tree when I’m just doing simple undo. You
can definitely try it using transient keymaps
Yuan
Re: [ELPA] propose to add vundo.el to ELPA, Philip Kaludercic, 2022/04/05
Re: [ELPA] propose to add vundo.el to ELPA, Stefan Monnier, 2022/04/06