[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change c7a660

From: Stefan Monnier
Subject: Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change c7a6601 1/5: undo-size can count number of boundaries.
Date: Wed, 23 Sep 2015 09:44:52 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>> But I get the impression that you didn't pay attention to another part
>> of the logic that we need: the part that pushes a boundary at the end of
>> a command.  Currently this is done in the C code and is applied only to
>> the current buffer, but we should change this so it is applied to all
>> buffers that were modified during the last command.
> Hmmm, indeed, no I have not done that.  I can add this.

To me, this is the most important part that relates to your original problem.

> Does this not obviate the need for the timer.

Not more than the current "push boundary when modifying another buffer".

> A long running process buffer in an otherwise idle Emacs would be
> a counter example, perhaps?

That's right.

> But it's easy to make the change. My thought was simply to leave the
> undo-list as untouched as much as possible.

Since it would only apply to changes made outside of commands,
i.e. changes from process filters and timers, I don't think "leave the
undo-list as untouched as much as possible" is desirable.  The fact that
we currently never push a boundary (except when some other buffer
happens to be modified) is just an accident.

>> and would remove the need for undo-buffer-undoably-changed.
> Unfortunately not!

I meant in the C code.  The C code would only need to trigger the Elisp
code when a change is made in a buffer which was previously "at an undo
boundary".  Of course, the Elisp code will then want to remember those
buffers "in need of a boundary" somehow (probably via a list like


reply via email to

[Prev in Thread] Current Thread [Next in Thread]