Re: disabling undo boundaries

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>>> Anyway, the patch is there. Any chance? If not, anything (further) that
>>> I can add (or remove!) to the branch to make it happen?
>> I'll try and look at it soon,
>
> IIUC this only removes the code which adds a boundary when we change
> buffer.   IOW it switches from the conservative option of adding
> a boundary even if it might not be needed, to the risky option of hoping
> that someone else will add the needed boundary.

I'd tend to characterise it as the risky option of disrupting the user
experience by added unnecessary boundaries on the off-chance of using
too much memory, against the conservative option of not adding a
boundary.

But, otherwise, yes.


> As explained, this will most likely introduce problems with ever-growing
> undo-logs in buffers filled by process output and timers.

Will buffer-undo-list not be truncated by GC anyway? I can't quite
understand where the ever-growing logs come from, nor how the
functionality I have removed would prevent it.

> It's an acceptable first step, but it needs to be compensated by
> a second step which keeps track of all buffers modified during the
> execution of a command and change the "add a boundary in current-buffer
> at the end of a command" to "add boundaries in all modified buffers
> at the end of a command".

I'm struggling with understanding this also. I've tried tracing when the
code my patch removes actually runs and it is pretty rarely. And, yet,
undo works correctly, generally on a per-command basis (except for the
self-insert-command special handling).

Also, adding boundaries in all modified buffers strikes me as fairly
stochastic. Assuming a well-behaved timer (i.e. one that releases
control with `sit-for'), this logic essentially translates to "we may
choose to show an undo-boundary in at this point, or we may not".

So I'd need an example, though, or some way of causing this sort of
problem that you are worried about. A failing ert test in
test/automated would be ideal, but anything is good!

Phil