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: Tue, 27 Oct 2015 12:45:22 +0000 Message-ID: <87wpu8lbtp.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445949946 10279 80.91.229.3 (27 Oct 2015 12:45:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Oct 2015 12:45:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 27 13:45:42 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 1Zr3dD-0007jg-4d for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 13:45:39 +0100 Original-Received: from localhost ([::1]:59399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr3dC-0001iK-6z for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 08:45:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr3d5-0001i3-FK for emacs-devel@gnu.org; Tue, 27 Oct 2015 08:45:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr3d1-0000ej-Th for emacs-devel@gnu.org; Tue, 27 Oct 2015 08:45:31 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:47679) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr3d1-0000d0-O4 for emacs-devel@gnu.org; Tue, 27 Oct 2015 08:45:27 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1Zr3cw-0000iT-FY; Tue, 27 Oct 2015 12:45:22 +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 1Zr3cw-0000Ps-I9; Tue, 27 Oct 2015 12:45:22 +0000 In-Reply-To: (Stefan Monnier's message of "Mon, 26 Oct 2015 13:56:37 -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.22 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:192716 Archived-At: Stefan Monnier writes: >> But, after self-insert-command, actually, undo-undoably-changed-buffers >> tells all the buffers that were modified since the last time we added an >> auto-boundary. This will only be the same as the buffers which have >> changed as a result of self-insert-command iff >> undo-undoably-changed-buffers was nil before the command. It need not be >> if buffers are undoably-changing as a result of a timer or a process for >> instance. > > Indeed, with process filters and such there's a real probability that > this isn't the case. I think we can avoid this problem by making > self-insert-command explicitly call undo-auto-boundaries at its end. > >> My other concern is that after a self-insert-command, I can guarantee >> that the current-buffer hasn't changed much (normally by one char). But, >> for example, with lentic a self-insert-command in one buffer can in >> worse case result in all the characters in another buffer changing. > > In the worst case self-insert-command can also change the whole buffer. > So the worst case is not nearly as important as the "reasonably expectable > cases". In the case of lentic, the worst case is, unfortunately, not uncommon. Original it happened every key press, not it is rare enough not to cause noticable lag, but it is enough to add a lot of stuff into buffer-undo-list. >> So amalgamating these changes might result in a big buffer-undo-list. > > I don't see how/why the size of buffer-undo-list would be affected. Oh, sorry, I mean, "big" in the sense of "big chunks between boundaries" which in turn means "not open for GC". Regardless, I've made the changes, and pushed them. 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. Other than this, are these changes ready to go? Phil