Re: disabling undo boundaries

[Phillip Lord]

Phillip Lord <address@hidden> writes:

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

Okay, to answer my own question, this *is* already handled at GC, with
the undo-outer-limit logic. Not handled ideally -- undo-outer-limit is
two orders greater than normal and the compaction function is noisy. But
it should stop Emacs from memory leaking to crash.

Phil