Re: disabling undo boundaries

[Phillip Lord]

Phillip Lord <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>
>>> Actually, I have been thinking about this. What I worry about with this
>>> is that we may be adding the same form of heuristic into undo.c as the
>>> "insert an undo-boundary if the buffer has changed".
>>
>> Yes, because we do want this to happen, pretty much always (having
>> changes accumulate without intervening boundary is actually a problem
>> that can lead to nasty behaviors).
>>
>> There are exceptions, but they're rare.
>
>
> Sorry for late reply -- been travelling.
>
> The heuristic I was refering to is the "insert an undo-boundary if the
> current-buffer has changed". Or, rather, insert an undo-boundary if some
> *other* buffer has changed.
>
> I think that the current undo-boundary behaviour wrt a single buffer
> makes sense. It's the fact that inserting content into *that* buffer
> forces an undo-boundary into *this* buffer. I don't know why Emacs does
> this. In most cases, this is irrelevant and doesn't happen anyway, and
> where you have a p-c-h or a-c-f it changes undo behaviour. I worry that
> I am missing a good reason for this behaviour, but I have thought about
> it and failed to come up with a reason; negative conclusions are always
> worrisome, but what else can you do?
>
> I'll write a patch to trunk and send it in, once my life has caught up,
> then I can happily pass the buck of making the final decision to you:-)

I have added the change that I am suggesting to:

fix/no-undo-boundary-on-secondary-buffer-change

The change simplifies undo.c somewhat. I can see no reason for the
existing logic, and it is has extremely counter-intuitive consequences
when using as discussed when using post-c-h or a-c-f.

But clearly it also changes some deep (and old!) logic in undo.c. So,
making this my first commit to trunk would clearly be reckless.

Let me know what you think. If you are unhappy, I will drop the idea
entirely and delete the branch. If you are happy, I will leave you to
merge/rebase as you choose. If you don't like my commit message grammar,
I can fix and squash on a branch!

Cheers

Phil