From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: disabling undo boundaries Date: Wed, 13 May 2015 16:40:56 +0100 Message-ID: <87sib0a3jr.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <87617zl4kh.fsf@newcastle.ac.uk> <87h9rjhy8w.fsf@newcastle.ac.uk> <87oalqrgm7.fsf@newcastle.ac.uk> <87ioby3tdy.fsf@newcastle.ac.uk> <87y4kth5ps.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1431531671 6384 80.91.229.3 (13 May 2015 15:41:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 May 2015 15:41:11 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 13 17:41:11 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 1YsYmV-0005nu-5H for ged-emacs-devel@m.gmane.org; Wed, 13 May 2015 17:41:11 +0200 Original-Received: from localhost ([::1]:49698 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsYmU-0005IR-Gk for ged-emacs-devel@m.gmane.org; Wed, 13 May 2015 11:41:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsYmQ-0005FP-C7 for emacs-devel@gnu.org; Wed, 13 May 2015 11:41:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsYmL-0004Kq-GQ for emacs-devel@gnu.org; Wed, 13 May 2015 11:41:06 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:53453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsYmL-0004It-AR for emacs-devel@gnu.org; Wed, 13 May 2015 11:41:01 -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 1YsYmH-0005B4-Et; Wed, 13 May 2015 16:40:57 +0100 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 1YsYmH-0008S8-Bg; Wed, 13 May 2015 16:40:57 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 13 May 2015 08:32:59 -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:186479 Archived-At: Stefan Monnier writes: >> My fault for not being clear. AFAICT, undo-boundary does not set >> last_undo_buffer at all. > > Oh, indeed, it sets last_boundary_buffer but not last_undo_buffer! > Duh! > >> I'm still trying to understand the reason behind the logic in the first >> place; unfortunately, the code seems to predate the earliest VC records. > > IIUC the reason is for modifications in another buffer that take place > either within a command or between commands (e.g. process output), so > they don't accumulate arbitrarily within a single undo-boundary. > > E.g. if you have a command "add timestamp to log buffer" which you > typically use from another buffer then, without this logic, running this > command 100 times would result in all entries in the buffer being lumped > together into a single undo-unit, so you couldn't undo them separately. In the other buffer? So, you can undo the changes to the log buffer one after the other? I agree that makes sense, but it does seem to me that this could be the responsibility of "add timestamp to log buffer". I'm checking at the moment how often this undo-boundary gets called. So far, it's about 1.5% of the time that an undo event gets added, so it's not very often (obviously this is without an a-c-f entry or it would be much higher!). Phil