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 c7a6601 1/5: undo-size can count number of boundaries. Date: Mon, 28 Sep 2015 20:37:29 +0100 Message-ID: <87a8s61gjq.fsf@russet.org.uk> References: <20150915152129.671.61929@vcs.savannah.gnu.org> <8761395uxx.fsf@russet.org.uk> <8737yd2iju.fsf@russet.org.uk> <87k2rizq9w.fsf@russet.org.uk> <874mim6sj2.fsf@russet.org.uk> <877fnh8r73.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443488930 1489 80.91.229.3 (29 Sep 2015 01:08:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2015 01:08:50 +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 Sep 29 03:08: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 1ZgjPJ-0006RW-Ng for ged-emacs-devel@m.gmane.org; Tue, 29 Sep 2015 03:08:37 +0200 Original-Received: from localhost ([::1]:43466 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgjPJ-0007fn-3w for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 21:08:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgeFA-0004j3-0a for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:37:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgeF6-0005cD-JY for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:37:47 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:52226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgeF6-0005Zi-DM for emacs-devel@gnu.org; Mon, 28 Sep 2015 15:37:44 -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 1ZgeEy-00083i-Fe; Mon, 28 Sep 2015 20:37:36 +0100 Original-Received: from cpc6-benw10-2-0-cust45.gate.cable.virginm.net ([92.238.179.46] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZgeEx-0006Sq-PQ; Mon, 28 Sep 2015 20:37:35 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 23 Sep 2015 09:44:52 -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:190459 Archived-At: Stefan Monnier writes: >>> But I get the impression that you didn't pay attention to another part >>> of the logic that we need: the part that pushes a boundary at the end of >>> a command. Currently this is done in the C code and is applied only to >>> the current buffer, but we should change this so it is applied to all >>> buffers that were modified during the last command. >> Hmmm, indeed, no I have not done that. I can add this. > > To me, this is the most important part that relates to your original problem. > >> Does this not obviate the need for the timer. > > Not more than the current "push boundary when modifying another buffer". > >> A long running process buffer in an otherwise idle Emacs would be >> a counter example, perhaps? > > That's right. > >> But it's easy to make the change. My thought was simply to leave the >> undo-list as untouched as much as possible. > > Since it would only apply to changes made outside of commands, > i.e. changes from process filters and timers, I don't think "leave the > undo-list as untouched as much as possible" is desirable. The fact that > we currently never push a boundary (except when some other buffer > happens to be modified) is just an accident. > >>> and would remove the need for undo-buffer-undoably-changed. >> Unfortunately not! > > I meant in the C code. The C code would only need to trigger the Elisp > code when a change is made in a buffer which was previously "at an undo > boundary". Of course, the Elisp code will then want to remember those > buffers "in need of a boundary" somehow (probably via a list like > undo-undoably-change-buffers). Okay this is, I believe, done now. It's a good deal simpler than it was, which has to be a positive thing. I am still not entirely convinced -- I think that the "default" undo-boundary behaviour should be to do as little as possible, but the logic is implemented in lisp now, so it can be over-ridden more straight-forwardly if needed. It would also be possible to add a buffer-local variable `undo-no-auto-boundary' to switch this behaviour off, as opposed to changing global state, but adding that seems like overkill at the moment. I've put some ad-hoc logging in; the code runs post-command and on a timer and mostly silently, so it's hard to test it in actual use in any other way. Obviously, I plan to remove that afterwards. Comments welcome. Phil