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: undo refactoring Date: Tue, 05 Jul 2016 23:22:49 +0100 Message-ID: <877fczd8sm.fsf@russet.org.uk> 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 1467757423 10386 80.91.229.3 (5 Jul 2016 22:23:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2016 22:23:43 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 00:23:34 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 1bKYkf-0005D0-FC for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2016 00:23:33 +0200 Original-Received: from localhost ([::1]:58368 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKYke-0001h4-Na for ged-emacs-devel@m.gmane.org; Tue, 05 Jul 2016 18:23:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKYk3-0001gc-M1 for emacs-devel@gnu.org; Tue, 05 Jul 2016 18:22:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKYjz-0004DA-Kc for emacs-devel@gnu.org; Tue, 05 Jul 2016 18:22:55 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:52081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKYjz-0004Cs-Cb for emacs-devel@gnu.org; Tue, 05 Jul 2016 18:22:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=l+wudFdHng58KOzpRAfOoQEOx4f9f5yEXafl0sDIW7I=; b=mDq7XWAll7n49oZ6NP5g4PMCE5 LSDm9KeAEzc1BdKNg2E+r0masB34F9mJ5JMpYcG5h6sR7Xn88OS2dsRzrlJpHYQ6GdBQusTyaq3Mq tcpoe11hQWqOENhEwITaWYfz2nOojg94BeTR+wVta8X7mLy0CE7pmDnuXVtgQeMHc1/DuHgejMrGZ j8SpCCs+DqeAeDyNzL1Ks46LfGp63dPzGMChT7LSNgVOwweFVXaBZVivkmU6Z+vgIcn+CBtalcSuA KJqu+AuO6fjdXRCgiqoqqNqwz1N+vkJdCnK6Q6cPjYGLCPe24wY6E/GI58lsRtstQw+fe41tk5252 Lt36zPdg==; Original-Received: from cpc1-benw10-2-0-cust373.gate.cable.virginm.net ([77.98.219.118]:53276 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1bKYjy-0024ia-IC; Tue, 05 Jul 2016 23:22:50 +0100 In-Reply-To: (Stefan Monnier's message of "Tue, 05 Jul 2016 17:50:28 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 31.216.48.48 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:205215 Archived-At: Stefan Monnier writes: > 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. Found the documentation (near the variable rather than the method), and yes, it's about memory allocation. /* The first time a command records something for undo. it also allocates the undo-boundary object which will be added to the list at the end of the command. This ensures we can't run out of space while trying to make an undo-boundary. */ That comment was from Richard, and hasn't changed since 1994; I guess the chance of memory issues from a cons or two are less of a problem now. > > 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. I've experimented with this and, at least, all the tests work. I'll try it out in actual use, then if you are happy make the change on master. Phil