Re: disabling undo boundaries

[Stefan Monnier]

>> So, while it clearly has an effect, I am not sure why this is better.
>> For example, if I launch two shell buffers, then run "countdown 20" in
>> both at the same time, then both buffers now undo in 20 steps, one
>> second at a time, because their output interleaves. Again, the "add an
>> undo boundary because of a change in another buffer" semantics does not
>> seem intuitive to me.

Agreed.

> Just wanted to bump this. I am still not sure why this is a good
> behaviour. My own feeling is that the "undo-boundary when a buffer
> change happens" logic may not have been implemented for this reason, but
> as a belts-and-braces way of detecting the end of a command -- after
> all, buffer changes (followed by an undoable event) normally happen
> between commands rather than within.

For process filters, I think the "right way" would be to add an
undo-boundary every N insertions.

> I did start working on this, but haven't got it functional yet. One
> problem is that if I record the cons cell at the head of
> buffer-undo-list, I have to search the whole buffer-undo-list to see if
> it is there (unless I get a match). A cons cell with a nil gets added
> for every self-insert-command and then removed again, so this tends to
> happen quite a lot.

Sounds rather ugly.  Let's see how far we can go with the option of
changing the current behavior rather than trying to add workarounds in
your code.

Could you describe the exact case that bothers you, so we could start by
thinking what should be the ideal behavior for that one?


        Stefan