From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Martin Pohlack Newsgroups: gmane.emacs.bugs Subject: bug#11774: [O] bug#11774: org-mode causes undo boundaries to be lost Date: Tue, 03 Jul 2012 17:18:40 +0200 Message-ID: <4FF30D50.8010009@os.inf.tu-dresden.de> References: <20120703095729.GA6651@c3po> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1341328798 3732 80.91.229.3 (3 Jul 2012 15:19:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2012 15:19:58 +0000 (UTC) Cc: Bastien , 11774@debbugs.gnu.org To: Toby Cubitt Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 03 17:19:55 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Sm4tK-0000PO-SW for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2012 17:19:51 +0200 Original-Received: from localhost ([::1]:56882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm4tJ-0007IC-Mr for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2012 11:19:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm4tC-00071A-VS for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 11:19:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sm4t6-0003NY-M2 for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 11:19:42 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm4sq-0003In-QC; Tue, 03 Jul 2012 11:19:20 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sm4xO-0002RN-1V; Tue, 03 Jul 2012 11:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Martin Pohlack Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Tue, 03 Jul 2012 15:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11774 X-GNU-PR-Package: emacs,org-mode X-GNU-PR-Keywords: Original-Received: via spool by 11774-submit@debbugs.gnu.org id=B11774.13413290089341 (code B ref 11774); Tue, 03 Jul 2012 15:24:02 +0000 Original-Received: (at 11774) by debbugs.gnu.org; 3 Jul 2012 15:23:28 +0000 Original-Received: from localhost ([127.0.0.1]:45379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sm4wq-0002Qc-DN for submit@debbugs.gnu.org; Tue, 03 Jul 2012 11:23:28 -0400 Original-Received: from os.inf.tu-dresden.de ([141.76.48.99]:35412) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sm4wo-0002QT-4N for 11774@debbugs.gnu.org; Tue, 03 Jul 2012 11:23:27 -0400 Original-Received: from [217.9.48.20] (helo=[165.204.15.163]) by os.inf.tu-dresden.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) id 1Sm4sD-0000eR-CJ; Tue, 03 Jul 2012 17:18:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 In-Reply-To: <20120703095729.GA6651@c3po> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:61526 Archived-At: On 03.07.2012 11:57, Toby Cubitt wrote: > On Mon, Jul 02, 2012 at 08:51:48AM +0200, Martin Pohlack wrote: >>> I'm still not entirely convinced that the boundary discarding logic in >>> org-self-insert-command is correct. For example, if I do the following: >>> >>> 1. Type some text at some location in an org-mode buffer >>> 2. Move to another location very far away >>> (without invoking any commands other than point motion) >>> 3. Type some more text >>> >>> then org-self-insert-cluster-for-undo collapses the undo changesets for >>> these two changes into one. Undoing then reverts both sets of changes at >>> once, even though those changes might be so far apart that they aren't >>> both visible at the same time in the buffer. >>> >>> That seems very undesirable to me. >> >> Having been involved in org-mode's collapsing code I am interested in >> this, but I cannot reproduce your problem. I used a very large org-mode >> file, inserted some text, moved down some pages and inserted some text >> again (3 chars each). Undoing was split between both parts, exactly as >> desired. Could you provide more details please? > > > Sure. The following steps produce the effect I described, at least for > me. This is on a fairly recent (a couple of weeks old) bzr build of > Emacs, and a similarly recent git build of org-mode: > > 1. $ emacs -Q > 2. C-x C-f test.org > 3. M-x org-mode [not really necessary since already in org-mode] > 5. C-u 50 M-x newline > 6. M-< > 7. type "a" > 8. M-> > 9. type "bc" > > buffer-undo-list now contains: > > (nil (52 . 54) (1 . 2) nil (1 . 51) (t . -1)) > > Note the lack of undo boundary between (52 . 54) and (1 . 2), which means > that undoing once (C-/) deletes both "bc" *and* "a" in one step. Understood. I tried exactly the same thing with an older emacs (GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.4) of 2011-04-04 on crested, modified by Debian) and org-mode (6.33x and 7.6) and have this result: (nil (53 . 54) (52 . 53) nil (1 . 2) nil (1 . 51) (t 65535 . 65535)) Which is what one wants. Someone seems to be merging the self-insert commands in your situation. Probably the native merging code has changed in recent emacs itself. If this is confirmed, we could modify org-mode's merging code to only merge undo entries that span one character. Martin