From: phillip.lord@russet.org.uk (Phillip Lord)
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change f59d1be: Move undo amalgamation to lisp.
Date: Thu, 29 Oct 2015 14:44:34 +0000 [thread overview]
Message-ID: <87a8r13fal.fsf@russet.org.uk> (raw)
In-Reply-To: <jwvmvv3rvvb.fsf-monnier+emacsdiffs@gnu.org> (Stefan Monnier's message of "Wed, 28 Oct 2015 09:05:18 -0400")
Stefan Monnier <monnier@IRO.UMontreal.CA> 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
next prev parent reply other threads:[~2015-10-29 14:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20151005134118.10933.50859@vcs.savannah.gnu.org>
[not found] ` <E1Zj610-0002qx-SM@vcs.savannah.gnu.org>
2015-10-05 15:15 ` [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change f59d1be: Move undo amalgamation to lisp Stefan Monnier
2015-10-05 16:24 ` Phillip Lord
2015-10-07 19:28 ` Stefan Monnier
2015-10-08 19:56 ` Phillip Lord
2015-10-08 20:53 ` Stefan Monnier
2015-10-09 8:31 ` Phillip Lord
2015-10-16 21:02 ` Phillip Lord
2015-10-18 16:51 ` Stefan Monnier
2015-10-21 19:27 ` Phillip Lord
2015-10-26 17:56 ` Stefan Monnier
2015-10-27 12:45 ` Phillip Lord
2015-10-27 14:50 ` Stefan Monnier
2015-10-28 10:01 ` Phillip Lord
2015-10-28 13:05 ` Stefan Monnier
2015-10-29 14:44 ` Phillip Lord [this message]
2015-10-29 15:47 ` Stefan Monnier
2015-10-30 8:44 ` Phillip Lord
2015-10-30 13:28 ` Stefan Monnier
2015-10-30 14:21 ` David Kastrup
2015-11-02 16:56 ` Phillip Lord
2015-11-02 19:37 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a8r13fal.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.