From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: undo refactoring Date: Tue, 05 Jul 2016 17:50:28 -0400 Message-ID: References: <83h9cavdgj.fsf@gnu.org> <87poqyy2tc.fsf@metalevel.at> <87vb0qqrkz.fsf@russet.org.uk> <87h9c9zx75.fsf@metalevel.at> <834m89vmyv.fsf@gnu.org> <878txlsbdb.fsf@russet.org.uk> <87furtccdv.fsf@metalevel.at> <877fd5q9te.fsf@russet.org.uk> <83bn2gtruk.fsf@gnu.org> <87k2h37pvb.fsf@russet.org.uk> <87vb0lta67.fsf@russet.org.uk> <8760skcw09.fsf_-_@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1467755509 11308 80.91.229.3 (5 Jul 2016 21:51:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2016 21:51:49 +0000 (UTC) Cc: Emacs-Devel devel To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 05 23:51:36 2016 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 1bKYFk-0003HQ-7f for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2016 23:51:36 +0200 Original-Received: from localhost ([::1]:58248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKYFg-0003iK-3n for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2016 17:51:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKYEs-0003ga-5U for emacs-devel@gnu.org; Tue, 05 Jul 2016 17:50:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKYEo-0007tj-HD for emacs-devel@gnu.org; Tue, 05 Jul 2016 17:50:41 -0400 Original-Received: from smtp-as-01-06.vtxnet.net ([194.38.175.135]:47439 helo=smtp-as-01.vtxnet.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKYEo-0007tB-52 for emacs-devel@gnu.org; Tue, 05 Jul 2016 17:50:38 -0400 Original-Received: from smtp-as-01.vtxnet.net (smtp-as-01-04.vtxnet.net [194.38.175.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-as-01.vtxnet.net (Postfix) with ESMTPS id 3548B43B66; Tue, 5 Jul 2016 23:50:35 +0200 (CEST) Original-Received: from smtp-pri-02.vtxnet.net (smtp-pri-02-1.vtxnet.net [212.147.62.146]) by smtp-as-01.vtxnet.net (Postfix) with ESMTP id 4A3FC43B8E; Tue, 5 Jul 2016 23:50:31 +0200 (CEST) Original-Received: from fmsmemgm.homelinux.net (dyn.144-85-234-142.dsl.vtx.ch [144.85.234.142]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-pri-02.vtxnet.net (VTX Services SA) with ESMTP id 3D20137DCD4; Tue, 5 Jul 2016 23:50:31 +0200 (CEST) Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 41E82AE0BC; Tue, 5 Jul 2016 17:50:28 -0400 (EDT) In-Reply-To: <8760skcw09.fsf_-_@russet.org.uk> (Phillip Lord's message of "Tue, 05 Jul 2016 09:46:46 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 194.38.175.135 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:205212 Archived-At: > Why not just do > bset_undo_list (current_buffer, > Fcons (Qnil, BVAR (current_buffer, undo_list))); > and remove all references to pending_boundary (and therefore > `prepare_record` which is now rather badly named)? Or am I missing > something IIUC, the reason for this was so as to avoid an inf-loop when malloc fails (for lack of memory). The particular issue was that it was OK for a command to fail because of malloc failure, but it was not OK for the read-eval-loop itself to fail before having the opportunity to run another command. My impression is that this design goal has been ignored for much too long, so I don't think Emacs behaves this way any more. And instead we have now other ways to handle the memory-full situation (such as the extra memory that's pre-allocated and then released in case the memory is full). IOW, I'd be surprised if getting rid of this quirk would ever lead to a visible change in Emacs's behavior nowadays. Stefan