Re: disabling undo boundaries

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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
difficult/tricky/risky.

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.


        Stefan