Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change f59d1be: Move undo amalgamation to lisp.

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>>> I have noticed one problem case. The *scratch* buffer is created without
>>> an undo-boundary after the ";;; This buffer is..." message. I think this
>>> is a bootstrap problem and can be fixed by adding an undo-boundary call
>>> to startup.el.
>> 
>> The boundary is supposed to be added just before the first command
>> (since undo-boundaries are added by the command loop right before
>> running a command).  so maybe the problem is that it doesn't get added
>> to your list of "buffers with undo elements"?

> I'm working on this, although it's hard to work out. Is Emacs even in
> the command loop when it runs startup.el?

No, but that doesn't matter: before you hit your first key, there won't
be any undo-boundary, but as long as the *scratch* buffer is in the list
of "buffers with undo elements", that's OK because it means that as
soon as you hit the first key, just before running this first command,
the command-loop (in which we are as soon as Emacs sits there waiting
for us to hit the first key) should call undo-auto-boundaries (assuming
your patch indeed calls undo-auto-boundaries *before* rather than
*after* running the command).

> My inclination would be to just put an explicit "undo-boundary" into
> startup, as it is more straight-forward than working my way through the
> emacs boot process.

That's fine, indeed.

>>> Other than this, are these changes ready to go?
>> I'll let you know as soon as I find the time to review it,
> Apologies! I didn't mean to appear to nag. I am quite patient
> (especially at this time of year).

No worries, I didn't read it as a nag.


        Stefan