Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change c7a6601 1/5: undo-size can count number of boundaries.

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> Okay. So, I'll recap, and then explain the logic that I am trying to
>> implement.
>
> So, IIUC this undo-buffer-undoably-changed is meant to distinguish "new
> change since boundary" from "new change since last timer run").

Not sure "distinguish" is correct. Yes, it implements the "new change
since last timer run" logic. I am not using "new change since boundary"
(which as you say can be determined by looking at buffer-undo-list).


> OK, so we were indeed miscommunicating.
>
> But I get the impression that you didn't pay attention to another part
> of the logic that we need: the part that pushes a boundary at the end of
> a command.  Currently this is done in the C code and is applied only to
> the current buffer, but we should change this so it is applied to all
> buffers that were modified during the last command.

Hmmm, indeed, no I have not done that. I can add this. Does this not
obviate the need for the timer. A long running process buffer in an
otherwise idle emacs would be a counter example, perhaps?

>> - every ten seconds check the size of the undo list, and iff it is
>>   bigger than undo-limit, and has less than 2 boundaries, add one at the
>>   start.
>
> Why not just unconditionally add a boundary (i.e. regardless of the undo
> list size)?  That would make it more useful (because more predictable
> and avoid too large undo steps)

I am not so sure about predictable. The issue here is that the timer
runs 10 seconds after any change at all. So, for a change in a
individual buffer, it could be at any time (10 seconds or less) after an
undoable-change.

But it's easy to make the change. My thought was simply to leave the
undo-list as untouched as much as possible.

> and would remove the need for undo-buffer-undoably-changed.

Unfortunately not! I am using this to enable the "first change"
functionality. I have to know which buffers have had a *recent* undoable
change *or* I have to signal all undoable changes.

I could remove this variable and use a list instead. In fact, that list
actually exists (undo-undoably-change-buffers). Equally, I could remove
that list, and filter all buffers for those where
undo-buffer-undoably-changed is t. Probably I should do at least the
latter since it's simpler, and cycling through all buffers at most every
10 seconds is not going to be a high cost operation.

Phil