[Top][All Lists]

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

Re: disabling undo boundaries

From: Stefan Monnier
Subject: Re: disabling undo boundaries
Date: Mon, 11 May 2015 10:45:49 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> The problem seems to come from here in record_point, in undo.c

>   if ((current_buffer != last_undo_buffer)
>       /* Don't call Fundo_boundary for the first change.  Otherwise we
>        risk overwriting last_boundary_position in Fundo_boundary with
>        PT of the current buffer and as a consequence not insert an
>        undo boundary because last_boundary_position will equal pt in
>        the test at the end of the present function (Bug#731).  */
>       && (MODIFF > SAVE_MODIFF))
>     Fundo_boundary ();
>   last_undo_buffer = current_buffer;

Oh, I think you're right, this is even more likely the reason for
those boundaries.

> The best thing that I can think of at the moment is to use
> post-command-hook to clean up the excessive undo-boundaries, but I am
> not sure how I am going to work out which ones are "real" and which ones
> not.  The obvious solution (delete all those adding since the last
> command) will fail for both self-insert-command's logic and anywhere
> else that undo-boundary has been explicitly called.

Indeed, removing those boundaries after the fact seems

I'm not sure exactly what are your design constraints, but I can see
a few alternatives:
- disable undo in the "other buffer" (*scratch* in your example, tho
  I suspect it's a different buffer in your real case).
- delay the modification of the other buffer (e.g. record in a-c-f the
  boundaries of the affected text, and process them later from
  post-command-hook).  Not sure if this would really help.
- change your a-c-f so it records the buffer-undo-list at the beginning,
  and it removes the added boundary (if any) at the end.


reply via email to

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