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:

>>>> +  if(NILP (Vundo_buffer_undoably_changed)){
>>>> +    Fset (Qundo_buffer_undoably_changed,Qt);
>>>> +    safe_run_hooks (Qundo_first_undoable_change_hook);
>>>> +  }
>>> Why do you need Vundo_buffer_undoably_changed?
>>> Doesn't (car-safe buffer-undo-list) give you the same information?
>> No. The point is that this can be reset when ever I choose, and so it
>> may well occur *not* after a boundary.
>
> But why would you want to set it not after a boundary?

Because I am using it to provide a backdrop, default, automatically add
a boundary heuristic. Waiting for a boundary to be added defeats the point.

>> hands of the lisp developer, since they can reset
>> "buffer-unably-changed" as they want, which will result in a new call
>> to the hook.
>
> When is this needed/useful?

When you want to store a list of all the buffers which have had undoable
changes recently. In this case, I am using this to work out which
buffers may need boundary. That's the point.

Also, it kicks off the timer which checks all buffers in this list to
see if any of them need a boundary.

Having it in lisp, I don't think you would need it. But you might need
it NOT to happen. The old heuristic of "add an undo if the any other
buffer has been written" caused my problems with lentic. This heuristic
will break sometime, somewhere (it's in the nature of heuristics). If it
is in lisp, it can be prevented, fixed or changed without having to
change the Emacs C layer and on a per buffer basis.

>> I have chosen not to add a "undoable-change" hook, because I didn't need
>> it. The first change hook calls rarely, so the performance issues with
>> handling this change in lisp are, I think, unimportant.
>
> Agreed.

Phil