Re: disabling undo boundaries

[Stefan Monnier]

>>> 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?

The general goal is: add undo-boundaries often enough so the undo-log
doesn't grow too large, both in FOO and in BAR, and ideally in ways
which are somewhat predictable for the user.

If you ask my ideal: FOO would get an undo-boundary after each command,
and BAR would get an undo boundary after each N bytes inserted, or after
every N seconds.

>>> 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.

In the scenario of "add boundaries to every buffer modified since last
time"?  Why do you think so?  The boundaries in Foo will not be
influenced by the timer.  The boundaries in Bar will, indeed, because
they'll only be inserted as a side-effect of the commands in Foo and
depending on how much you think, the timer could fire several times
between commands.  Hence my ideal wish of "get an undo boundary after
each N bytes inserted, or after every N seconds" for things like process
output or timers.

>>> 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.

Ah, you're thinking of a long-running idle-timer, basically a poor man's
background task.  Yes, then it needs to call sit-for, but I don't think
it makes much difference in the end result in the scenarios
discussed here.


        Stefan