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: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change e5ff575 2/2: Add a timer to ensure undo-boundaries in buffers. Date: Sat, 29 Aug 2015 23:30:13 -0400 Message-ID: References: <20150821093606.11577.60349@vcs.savannah.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1440905433 22955 80.91.229.3 (30 Aug 2015 03:30:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2015 03:30:33 +0000 (UTC) Cc: Phillip Lord To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 30 05:30:23 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 1ZVtK3-0007Hv-H9 for ged-emacs-devel@m.gmane.org; Sun, 30 Aug 2015 05:30:23 +0200 Original-Received: from localhost ([::1]:56254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVtK3-0007Ze-Ba for ged-emacs-devel@m.gmane.org; Sat, 29 Aug 2015 23:30:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVtK1-0007ZX-0Q for emacs-devel@gnu.org; Sat, 29 Aug 2015 23:30:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVtJv-0002Pd-W7 for emacs-devel@gnu.org; Sat, 29 Aug 2015 23:30:20 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:10395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVtJv-0002PG-RB for emacs-devel@gnu.org; Sat, 29 Aug 2015 23:30:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CsCwA731xV/8Fw3mhcgxCEAsEMCYdLBAICgTw5FAEBAQEBAQGBCkEFg10BAQRWIxALNAcLFBgNiGPPIwEBAQcBAQEBHos6hC1YBxaEFwEEtQQjgWZVgVkigTWBQwEBAQ X-IPAS-Result: A0CsCwA731xV/8Fw3mhcgxCEAsEMCYdLBAICgTw5FAEBAQEBAQGBCkEFg10BAQRWIxALNAcLFBgNiGPPIwEBAQcBAQEBHos6hC1YBxaEFwEEtQQjgWZVgVkigTWBQwEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="161827517" Original-Received: from 104-222-112-193.cpe.teksavvy.com (HELO fmsmemgm.homelinux.net) ([104.222.112.193]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Aug 2015 23:30:13 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 3B840AE042; Sat, 29 Aug 2015 23:30:13 -0400 (EDT) In-Reply-To: (Phillip Lord's message of "Fri, 21 Aug 2015 09:36:08 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:189309 Archived-At: > +(defun undo-ensure-boundary () > + "Add an `undo-boundary' if `buffer-undo-list' is long. > + > +Return t if an undo boundary has been added. > + > +Normally, Emacs will only garbage collect data from > +`buffer-undo-list' when this list is longer than `undo-limit'. It > +then collects data from after the first `undo-boundary' after > +`undo-limit'. If there are no boundaries in the list, > +`buffer-undo-list' will grow until it reaches > +`undo-outer-limit' (by default a much larger value than > +`undo-limit'), when it will discard the data anyway. In this > +case, however, it is treated as an exceptional case, and the a > +warning is signalled. > + > +This function add an `undo-boundary' to `buffer-undo-list' if > +there is no other `undo-boundary', and `buffer-undo-list' is > +longer than `undo-limit'. It provides a useful default mechanism > +for adding an `undo-boundary' which retains data where possible, > +without signalling warnings to the user." I think this makes sense, but we should do it in the GC code, then. Stefan