Re: disabling undo boundaries

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> Will buffer-undo-list not be truncated by GC anyway?
>
> Truncation is only done at undo-boundaries.  Hence the problem.

Ah, yes, okay.


>> I'm struggling with understanding this also. I've tried tracing when the
>> code my patch removes actually runs and it is pretty rarely.
>
> When you're editing buffer FOO while some process is inserting data in
> buffer BAR.

Okay. So, buffer BAR should get undo-boundaries when a command runs in
FOO? And FOO should get an undo-boundary when the process adds something
to BAR?

> Or when your commands modify two buffers (e.g. in your case).

Well, I think that this is my problem (as the author of the command,
rather than as the user). I mean, I modify two buffers, I need to fix
the undo, to decide what I want to do about this.

For my use case, this would work much better because I could even do the
"undo-boundary unless it's self-insert in which case wait for 20 of
them" logic.

In the case of a logging mode (i.e. which logs all events), I'd switch
the undo off in that buffer anyway.


>> Also, adding boundaries in all modified buffers strikes me as fairly
>> stochastic.
>
> Not sure what you mean.

I am editing a buffer, FOO. I type something in the usual way, with some
pauses for me to think.

Mean time, an idle-timer is running, doing something to BAR. If I think
long, the undo will behave in one way, if I think quick, the undo will
behave in another, depending on whether the idle-timer has modified BAR
or not.

>
>> Assuming a well-behaved timer (i.e. one that releases
>> control with `sit-for'),
>
> Hmm?  timers usually shouldn't call sit-for.

Oh, now I am sure that this used to be recommended (which is why I did
it). I use this when I have a long running idle timer -- I sit-for a
very short gap, then carry on if there is no input pending, then carry
on.

Well, that's more code to fix!

Phil