Re: disabling undo boundaries

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

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

My own feeling is that undo-boundaries should be the task of the mode
author, with sensible default behaviour (like the current one) for
user-centric modes (i.e. non process buffers). My guess is that most
buffers connected to non-interactive processes have undo switched off.

As an alternative, why not handle this at GC? So, change the current
logic to "iff buffer undo-log is too large, and you have no
undo-boundaries, GC to 50% of length regardless". This addresses your
concern (overly long undo-logs, i.e. memory leaks) within the memory
management system, rather than in as a heuristic in a user system (i.e.
undo).


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

Sorry, my mistake. "command" != function call. So, the call to the
idle-timer function will not trigger this.


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

Yeah, a "background" task. And you are correct.

Phil