nesting of unwind-protect and atomic-change-group

nesting of unwind-protect and atomic-change-group

[Roland Winkler]

When combining unwind-protect and atomic-change-group I found that
putting unwind-protect outermost worked for me (i.e., an unwindform
moving point to the buffer location where the error occured was
obeyed), whereas doing it the other way round didn't work for me
(the unwindform was ignored). 

Maybe the proper ordering of unwind-protect and atomic-change-group
is obvious for experts. Nonetheless, I suggest that this should be
documented in the docstring of atomic-change-group (as it is, e.g.,
for save-excursion and save-restriction.)

Roland


In GNU Emacs 22.1.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2007-10-15 on tfkp07
configured using `configure  '--prefix=/nfs/tfkp07/winkler/emacs/NEW' '--with-gcc' '--with-pop' '--with-x' '--with-x-toolkit=athena''

Re: nesting of unwind-protect and atomic-change-group

[Stefan Monnier]

> When combining unwind-protect and atomic-change-group I found that
> putting unwind-protect outermost worked for me (i.e., an unwindform
> moving point to the buffer location where the error occured was
> obeyed), whereas doing it the other way round didn't work for me
> (the unwindform was ignored). 

I'm pretty sure the unwind form is not ignored.  Maybe the unwind form
you tried happened to do something that's undone by the
atomic-change-group undoing of buffer changes?
Maybe this is even a bug in atomic-change-group.
So please spell out your test case,


        Stefan
.

Re: nesting of unwind-protect and atomic-change-group

[Richard Stallman]

    When combining unwind-protect and atomic-change-group I found that
    putting unwind-protect outermost worked for me (i.e., an unwindform
    moving point to the buffer location where the error occured was
    obeyed), whereas doing it the other way round didn't work for me
    (the unwindform was ignored). 

An unwind-protect will _work_ either inside or outside
of atomic-change-group.  Whatever problem you encountered
must be more specific.  I can't guess what it might be.

Please read the Bugs section in the Emacs manual, which provides
guidelines on how to write a bug report to give us the
necessary information so we can fix the bug.

Re: nesting of unwind-protect and atomic-change-group

[Roland Winkler]

On Sat Feb 2 2008 Richard Stallman wrote:
>     When combining unwind-protect and atomic-change-group I found that
>     putting unwind-protect outermost worked for me (i.e., an unwindform
>     moving point to the buffer location where the error occured was
>     obeyed), whereas doing it the other way round didn't work for me
>     (the unwindform was ignored). 
> 
> An unwind-protect will _work_ either inside or outside
> of atomic-change-group.  Whatever problem you encountered
> must be more specific.  I can't guess what it might be.

Thanks for clarifying this. My real-world example based on
bibtex-entry-format is too complicated as a test case. I'll boil it
down to something more amenable.

Roland

Re: nesting of unwind-protect and atomic-change-group

[Roland Winkler]

On Sat Feb 2 2008 Richard Stallman wrote:
>     When combining unwind-protect and atomic-change-group I found that
>     putting unwind-protect outermost worked for me (i.e., an unwindform
>     moving point to the buffer location where the error occured was
>     obeyed), whereas doing it the other way round didn't work for me
>     (the unwindform was ignored). 
> 
> An unwind-protect will _work_ either inside or outside
> of atomic-change-group.  Whatever problem you encountered
> must be more specific.  I can't guess what it might be.

OK, here is a test case, more or less similar to what I really want
to do, tested with emacs -q for GNU Emacs 22.1.2 (i686-pc-linux-gnu,
X toolkit, Xaw3d scroll bars)

When I run fun1 in a buffer containing the following lines of text

hello world bar
hello world bar
hello world foo
hello world bar
hello world bar

fun1 throws an error and puts point at the buffer location the error
refers to. fun2 does not put point at the buffer location that
corresponds to the error. The only difference between fun1 and fun2
is the order of unwind-protect and atomic-change-group.
(I find it counterintuitive that both functions put the message 
"search "foo"" in the *Messages* buffer before the error message,
but I expect that this has to do with how the error is handled.)

Roland


(defun fun1 ()
  "In current buffer replace word \"bar\" by \"baz\".
Throw error for word \"foo\" and move point to malicious word. Works"
  (interactive)
  (let (error-word)
    ;; `atomic-change-group' inside `unwind-protect'
    (unwind-protect
        (atomic-change-group
          (save-excursion
            (goto-char (point-min))
            (while (re-search-forward "\\<\\w+\\>" nil t)
              (let ((word (match-string 0)))
                (cond ((string= word "foo")
                       (setq error-word word)
                       (error "word \"foo\" in text"))
                      ((string= word "bar")
                       (replace-match "baz")))))))
      (when error-word
        (message "search \"foo\"")
        ;; move point to where error occured
        (goto-char (point-min))
        (re-search-forward "foo")
        (goto-char (match-beginning 0))))))

(defun fun2 ()
  "In current buffer replace word \"bar\" by \"baz\".
Throw error for word \"foo\". Code does not move point to malicious word"
  (interactive)
  (let (error-word)
    ;; `unwind-protect' inside `atomic-change-group'
    (atomic-change-group
      (unwind-protect
          (save-excursion
            (goto-char (point-min))
            (while (re-search-forward "\\<\\w+\\>" nil t)
              (let ((word (match-string 0)))
                (cond ((string= word "foo")
                       (setq error-word word)
                       (error "word \"foo\" in text"))
                      ((string= word "bar")
                       (replace-match "baz"))))))
        (when error-word
          (message "search \"foo\"")
          ;; move point to where error occured
          (goto-char (point-min))
          (re-search-forward "foo")
          (goto-char (match-beginning 0)))))))

Re: nesting of unwind-protect and atomic-change-group

[Stefan Monnier]

> fun1 throws an error and puts point at the buffer location the error
> refers to. fun2 does not put point at the buffer location that
> corresponds to the error. The only difference between fun1 and fun2
> is the order of unwind-protect and atomic-change-group.
> (I find it counterintuitive that both functions put the message 
> "search "foo"" in the *Messages* buffer before the error message,
> but I expect that this has to do with how the error is handled.)

When atomic-change-group undoes changes, it does it like "undo", which
means it also moves point.  That's what you're seeing: the goto-char in
your unwind-protect is "ignored" because the subsequent undo moves
point elsewhere.

Maybe we should wrap cancel-change-group within save-excursion, as in
the patch below?


        Stefan


--- orig/lisp/subr.el
+++ mod/lisp/subr.el
@@ -2008,6 +2008,7 @@
 (defun cancel-change-group (handle)
   "Finish a change group made with `prepare-change-group' (which see).
 This finishes the change group by reverting all of its changes."
+  (save-excursion
   (dolist (elt handle)
     (with-current-buffer (car elt)
       (setq elt (cdr elt))
@@ -2029,7 +2030,7 @@
 	  (setcar elt old-car)
 	  (setcdr elt old-cdr))
 	;; Revert the undo info to what it was when we grabbed the state.
-	(setq buffer-undo-list elt)))))
+          (setq buffer-undo-list elt))))))
 \f
 ;;;; Display-related functions.
 
.

Re: nesting of unwind-protect and atomic-change-group

[Stefan Monnier]

>>>>> "Roland" == Roland Winkler <Roland.Winkler@physik.uni-erlangen.de> writes:

> On Sat Feb 2 2008 Richard Stallman wrote:
>> When combining unwind-protect and atomic-change-group I found that
>> putting unwind-protect outermost worked for me (i.e., an unwindform
>> moving point to the buffer location where the error occured was
>> obeyed), whereas doing it the other way round didn't work for me
>> (the unwindform was ignored). 
>> 
>> An unwind-protect will _work_ either inside or outside
>> of atomic-change-group.  Whatever problem you encountered
>> must be more specific.  I can't guess what it might be.

> Thanks for clarifying this. My real-world example based on
> bibtex-entry-format is too complicated as a test case. I'll boil it
> down to something more amenable.

The patch below should make both cases work similarly.


        Stefan


--- orig/lisp/subr.el
+++ mod/lisp/subr.el
@@ -2008,6 +2008,7 @@
 (defun cancel-change-group (handle)
   "Finish a change group made with `prepare-change-group' (which see).
 This finishes the change group by reverting all of its changes."
+  (save-excursion
   (dolist (elt handle)
     (with-current-buffer (car elt)
       (setq elt (cdr elt))
@@ -2029,7 +2030,7 @@
 	  (setcar elt old-car)
 	  (setcdr elt old-cdr))
 	;; Revert the undo info to what it was when we grabbed the state.
-	(setq buffer-undo-list elt)))))
+          (setq buffer-undo-list elt))))))
 \f
 ;;;; Display-related functions.