From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel 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 Message-ID: <87a8r13fal.fsf@russet.org.uk> References: <20151005134118.10933.50859@vcs.savannah.gnu.org> <87h9m52sh8.fsf@russet.org.uk> <87h9lqbk8m.fsf@russet.org.uk> <87mvvc9g3m.fsf@russet.org.uk> <87wpu8lbtp.fsf@russet.org.uk> <87io5r5n2d.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446129994 6721 80.91.229.3 (29 Oct 2015 14:46:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Oct 2015 14:46:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 29 15:46:30 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZroTD-0008Ey-85 for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 15:46:27 +0100 Original-Received: from localhost ([::1]:44562 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZroTC-000092-OW for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 10:46:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZroRb-0006vB-JU for emacs-devel@gnu.org; Thu, 29 Oct 2015 10:44:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZroRX-0004ms-Fi for emacs-devel@gnu.org; Thu, 29 Oct 2015 10:44:47 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:45735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZroRX-0004m7-5L for emacs-devel@gnu.org; Thu, 29 Oct 2015 10:44:43 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1ZroRR-0004u9-BW; Thu, 29 Oct 2015 14:44:37 +0000 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZroRO-0003Lb-Fc; Thu, 29 Oct 2015 14:44:35 +0000 In-Reply-To: (Stefan Monnier's message of "Wed, 28 Oct 2015 09:05:18 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:192903 Archived-At: Stefan Monnier 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