[gnu.emacs.bug] minor bug in 18.52 rmail-message-labels-p

alarson@bozon.SRC.Honeywell.COM (Aaron Larson) (03/21/89)

It doesn't widen the region before making the check.  From rmail.el:

    ;; Return t if the attributes/keywords line of msg number MSG
    ;; contains a match for the regexp LABELS.
    (defun rmail-message-labels-p (msg labels)
      (goto-char (rmail-msgbeg msg))
      (forward-char 3)
      (re-search-backward labels (prog1 (point) (end-of-line)) t))

Should be:

    (defun rmail-message-labels-p (msg labels)
      (save-restriction
	(save-excursion
	  (widen)
	  (goto-char (+ 3 (rmail-msgbeg msg)))
	  (re-search-backward labels (prog1 (point) (end-of-line)) t))))

There are several functions in the same file that do the save-restriction
via let/unwind-protect.  Not actually wrong, but not very perspicuous
either. 

weltyc@cs.rpi.edu (Christopher A. Welty) (03/24/89)

In article <19095@srcsip.UUCP> alarson@bozon.SRC.Honeywell.COM (Aaron Larson) writes:
>
>It doesn't widen the region before making the check.  From rmail.el:
>    (defun rmail-message-labels-p (msg labels)
>
>Should be:
>
>    (defun rmail-message-labels-p (msg labels)
>      (save-restriction
>	(save-excursion
>	  (widen)
>	  (goto-char (+ 3 (rmail-msgbeg msg)))
>	  (re-search-backward labels (prog1 (point) (end-of-line)) t))))
>
>There are several functions in the same file that do the save-restriction
>via let/unwind-protect.  Not actually wrong, but not very perspicuous
>either. 

A couple of things: 

1) To make it more `perspicuous' this should be documented as well, but
wherever this function is called the rmail bufer is already widened
enough to read the labels.  Perhaps your code makes more sense.

2) Save-restriction isn't infallible, I seem to recall reading that
there are instances when it can forget the clipping marks...oh, if you
change something outside the cliping region the point gets screwed up,
which isn't actually the case here anyway... 

3) save-excursion should contain the save-restriction not the other
way around, I don't remember why, something similar to #2

4) unwind-protect is very important and does something completely
different than save-restriction, it protects you from errors.  If
there is an error in the middle of a save-restriction (or excursion)
you don't you back to the state you were trying to save.
unwind-potect insures that even if there is an error you will do some
finishing up before you return, so ie you can narrow your buffer
again.  Clear or not it's quite important.


Christopher Welty  ---  Asst. Director, RPI CS Labs | "Porsche:  Fahren in
weltyc@cs.rpi.edu             ...!njin!nyser!weltyc |  seiner schoensten Form"

alarson@quasar.SRC.Honeywell.COM (Aaron Larson) (03/27/89)

In article <985@rpi.edu> weltyc@cs.rpi.edu (Christopher A. Welty) writes:
   A couple of things: 
   ...
   4) unwind-protect is very important and does something completely
   different than save-restriction, it protects you from errors.  If
   there is an error in the middle of a save-restriction (or excursion)
   you don't you back to the state you were trying to save.
   unwind-potect insures that even if there is an error you will do some
   finishing up before you return, so ie you can narrow your buffer
   again.  Clear or not it's quite important.

It was my impression that save-restriction did an unwind-protect.  The
documentation for it does not say that it does, but according to the source
it does.  Your other points are well taken, and supported by the
documentation.  It pays to read...

weltyc@cs.rpi.edu (Christopher A. Welty) (03/29/89)

In article <19389@srcsip.UUCP> alarson@quasar.SRC.Honeywell.COM (Aaron Larson) writes:
>
>It was my impression that save-restriction did an unwind-protect.  The
>documentation for it does not say that it does, but according to the source
>it does.

You are quite right, my mistake.  


Christopher Welty  ---  Asst. Director, RPI CS Labs | "Porsche:  Fahren in
weltyc@cs.rpi.edu             ...!njin!nyser!weltyc |  seiner schoensten Form"