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

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>>>> 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).


At the moment, it's more *after* rather than *before*. I just put the
call into immediately after the second of the two calls to
post-command-hook. I will move it. How does the error handling work? If
the lisp called by

call1(Qcommand_execute, Vthis_command)

errors, I am guessing the stuff after it doesn't run? Rather, execution
passes to command_loop_2, which then re-enters? This would be another
reason to add it before, because I guess we should add an undo-boundary
if the command errors?

The positive side of this *scratch* buffer does eventually get an
undo-boundary, but only because of the timer I implemented. So, at least
now I am sure that this is working.


>> 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.


Thanks!

Phil