[O] bug#11774: bug#11774: org-mode causes undo boundaries to be lost
On 25.06.2012 13:35, Toby Cubitt wrote: > On Sun, Jun 24, 2012 at 11:52:41PM +0200, Toby Cubitt wrote: >> On Sun, Jun 24, 2012 at 11:39:08PM +0200, Bastien wrote: >>> Hi Toby, >>> >>> Toby Cubitt writes: >>> For some unknown reason, org-mode is causing the undo boundary between the (2 . 4) and (1 . 2) entries to be removed from `buffer-undo-list'. >>> >>> Can you try again with >>> >>> (setq org-self-insert-cluster-for-undo nil) >>> >>> and report? >> >> Yup, that fixes the problem. >> >> I don't fully understand the purpose of >> `org-self-insert-cluster-for-undo', given that the Emacs command loop >> already groups consecutive undo entries together, but presumably it >> enables a more aggressive form of clustering. Just to clarify this little piece here: I originally introduces this clustering code to mimic emacs' behavior in text mode. Org-mode's aggressive interception seemed to prevent that and undoing in org-mode felt unnatural compared to vanilla text mode. It was never meant to be *more* aggressive than emacs' original behavior. The grouping did not happen at the time. The original thread is here: http://lists.gnu.org/archive/html/emacs-orgmode/2009-02/msg00691.html Martin
[O] bug#11774: bug#11774: org-mode causes undo boundaries to be lost
> 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. Indeed, self-insert-command used to be treated specially by the read-eval-loop and the merging was performed there. Now this command is handled like any other, and self-insert-command does the merging itself. In most cases the result is the same, but the behavior is not quite identical in the details. Stefan
[O] bug#11774: bug#11774: org-mode causes undo boundaries to be lost
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. HTH, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
[O] bug#11774: bug#11774: org-mode causes undo boundaries to be lost
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
[O] bug#11774: bug#11774: org-mode causes undo boundaries to be lost
Hi Toby, On 25.06.2012 13:35, Toby Cubitt wrote: > On Sun, Jun 24, 2012 at 11:52:41PM +0200, Toby Cubitt wrote: >> On Sun, Jun 24, 2012 at 11:39:08PM +0200, Bastien wrote: >>> Hi Toby, >>> >>> Toby Cubitt writes: >>> For some unknown reason, org-mode is causing the undo boundary between the (2 . 4) and (1 . 2) entries to be removed from `buffer-undo-list'. >>> >>> Can you try again with >>> >>> (setq org-self-insert-cluster-for-undo nil) >>> >>> and report? >> >> Yup, that fixes the problem. >> >> I don't fully understand the purpose of >> `org-self-insert-cluster-for-undo', given that the Emacs command loop >> already groups consecutive undo entries together, but presumably it >> enables a more aggressive form of clustering. >> > [snip] >> >> I could try to work around this in undo-tree-mode, but it seems to me >> that org-mode shouldn't be throwing away an undo boundary that comes >> before an entry which definitely shouldn't be clustered with anything >> (namely the undo-tree-canary symbol, which is meaningless to org-mode). > > I've now added a work-around for this in undo-tree-mode (currently only > in git, but I'll push to ELPA once it's sufficiently tested). > > 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? Thanks, Martin
