Re: disabling undo boundaries

[Stefan Monnier]

>>> That doesn't really make sense to me. Say I am editing a file in this
>>> buffer while compiling something in that buffer. Why would I want an
>>> update in the compilation buffer to force an undo-boundary in this buffer?
>> It probably won't make any difference in "this buffer" because the
>> process filter will be run *between* commands (at which point the
>> read-eval command loop already inserts undo-boundaries anyway).
>> The difference is in the compilation buffer where it'll insert undo
>> boundaries every time you run a command in "this buffer".
> Yes, I can see that. Although iff this is the reason for the
> undo-boundary, it would still make more sense to me to have the process
> code insert this. Aside from being a more discrete effect, it would also
> avoid the current "do nothing now, but insert an undo-boundary before
> the next change where ever that is" semantics.

I don't claim it's the best solution, indeed.  It's just that if we
remove it, we'll have to replace it with other mechanisms.
So we need a clear description of the current cases that are considered
misbehaviors and those that are considered good (tho not necessarily
perfect).

> I don't understand how that would that work. undo-boundaries are nil, so
> surely they are all the same object?

No, we'd record put the cons cell in which the nil is placed.


        Stefan