Re: disabling undo boundaries

[Phillip Lord]

Phillip Lord <address@hidden> writes:
> Stefan Monnier <address@hidden> writes:
>
>> 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 entirely agree with this, of course. This is why I am trying to find
> positive behaviour.
>
> So, I have tested this, and indeed commenting out that code does affect
> undo behaviour. To test this, I wrote a "countdown" script which, well,
> counts down, and then ran this in *shell*. Then I typed into *scratch*
> at defined points. With the undo-boundary code, indeed, the typing in
> *scratch* does add boundaries -- so that a countdown from 100 say, gets
> split up into multiple undos. Without this code, the countdown gets
> undone in one go.
>
> 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.


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.



>>> 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.
>
> Oh, yes, of course. That does assume, though, that any operations on
> buffer-undo-list are destructive. For instance, if I filter the
> buffer-undo-list with seq.el or dash, do I not get all new cons cells?
> Still, most of the undo.c code seems to change in place, so I guess it
> would work in most cases.

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.

Phil