rmail-toggle-header problem

rmail-toggle-header problem

[Kenichi Handa]

When toggled, there's no empty line between header part and
body part like this:

[...]
Sender: emacs-devel-bounces+handa=m17n.org@gnu.org
Errors-To: emacs-devel-bounces+handa=m17n.org@gnu.org
X-RMAIL-ATTRIBUTES: --------
Hi,
omake prints progress bar using the usual ^M terminal trick.
[...]

And, the first "From ..." line is also shown.  Shouldn't
that line be hidden?  At least, C-c C-y (mail-yank-original)
signals this error:

Mail header "From harsh..." doesn't conform to RFC 822. skipping...

---
Kenichi Handa
handa@m17n.org

Re: rmail-toggle-header problem

[Glenn Morris]

(These things will be more traceable and less likely to be overlooked
if you report them as bugs.)

Kenichi Handa wrote:

> When toggled, there's no empty line between header part and
> body part like this:
>
> [...]
> Sender: emacs-devel-bounces+handa=m17n.org@gnu.org
> Errors-To: emacs-devel-bounces+handa=m17n.org@gnu.org
> X-RMAIL-ATTRIBUTES: --------
> Hi,
> omake prints progress bar using the usual ^M terminal trick.
> [...]

I think an example rmail file is needed, please. I tried to reproduce
this using the quoted message from emacs-devel but could not. (Note
that rms made some changes in this area very recently.)

> And, the first "From ..." line is also shown.  Shouldn't
> that line be hidden?  At least, C-c C-y (mail-yank-original)
> signals this error:
>
> Mail header "From harsh..." doesn't conform to RFC 822. skipping...

How are you getting that error? "doesn't conform to RFC 822" only
seems to be found in supercite. Arguably, supercite should be changed
instead to be more forgiving.

Re: rmail-toggle-header problem

[Kenichi Handa]

In article <gdmyckl3d1.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> (These things will be more traceable and less likely to be overlooked
> if you report them as bugs.)

Ah, sorry.  I at first started to write to emacs-devel as
for the second problem because I'm not sure it's a bug of
rmail-toggle-header, rmail-yank-original, or supercite.
Then, I noticed the first problem, and added that in the
mail.

> Kenichi Handa wrote:

> > When toggled, there's no empty line between header part and
> > body part like this:
> >
> > [...]
> > Sender: emacs-devel-bounces+handa=m17n.org@gnu.org
> > Errors-To: emacs-devel-bounces+handa=m17n.org@gnu.org
> > X-RMAIL-ATTRIBUTES: --------
> > Hi,
> > omake prints progress bar using the usual ^M terminal trick.
> > [...]

> I think an example rmail file is needed, please. I tried to reproduce
> this using the quoted message from emacs-devel but could not. (Note
> that rms made some changes in this area very recently.)

I found that this problem is fixed by today's update.

> > And, the first "From ..." line is also shown.  Shouldn't
> > that line be hidden?  At least, C-c C-y (mail-yank-original)
> > signals this error:
> >
> > Mail header "From harsh..." doesn't conform to RFC 822. skipping...

> How are you getting that error? "doesn't conform to RFC 822" only
> seems to be found in supercite.

My mail-citation-hook is (sc-cite-original).  So, yes, the
error is from supercite.  

> Arguably, supercite should be changed instead to be more
> forgiving.

Then, I propose this change (though I don't know if we need
a case-fold-search.

*** supercite.el.~1.69.~	2009-01-05 16:55:22.000000000 +0900
--- supercite.el	2009-02-18 15:35:35.000000000 +0900
***************
*** 704,709 ****
--- 704,710 ----
      ("^\\S +:.*$"                 (sc-mail-fetch-field) nil t)
      ("^$"                         (list 'abort '(step . 0)))
      ("^[ \t]+"                    (sc-mail-append-field))
+     ("^From "                     nil nil t)
      (sc-mail-warn-if-non-rfc822-p (sc-mail-error-in-mail-field))
      (end                          (setq sc-mail-headers-end (point))))
    "Regi frame for glomming mail header information.")

---
Kenichi Handa
handa@m17n.org

Re: rmail-toggle-header problem

[Richard M Stallman]

    When toggled, there's no empty line between header part and
    body part like this:

    [...]
    Sender: emacs-devel-bounces+handa=m17n.org@gnu.org
    Errors-To: emacs-devel-bounces+handa=m17n.org@gnu.org
    X-RMAIL-ATTRIBUTES: --------
    Hi,
    omake prints progress bar using the usual ^M terminal trick.
    [...]

I fixed that yesterday.

    And, the first "From ..." line is also shown.  Shouldn't
    that line be hidden?  At least, C-c C-y (mail-yank-original)
    signals this error:

I am not sure whether it is better to omit that line
or change mail-yank-original.

Re: rmail-toggle-header problem

[Glenn Morris]

Richard M Stallman wrote:

>     And, the first "From ..." line is also shown. Shouldn't that
>     line be hidden? At least, C-c C-y (mail-yank-original) signals
>     this error:
>
> I am not sure whether it is better to omit that line
> or change mail-yank-original.

I think Rmail might as well show the leading From line when full
headers are visible. It's simple to change mail-yank-original's
behaviour (see below).

I'm not sure that yanking from the full headers makes a lot of sense,
though. Eg it includes the X-RMAIL headers in the yank. Would you ever
want to include the full headers (all the Received: etc) in a reply?

Separately, I also don't know whether supercite should be changed as
was suggested.


*** rmail.el	19 Feb 2009 03:30:41 -0000	1.510
--- rmail.el	19 Feb 2009 20:23:16 -0000
***************
*** 3222,3232 ****
  \f
  ;;;; *** Rmail Mailing Commands ***
  
  (defun rmail-start-mail (&optional noerase to subject in-reply-to cc
  				   replybuffer sendactions same-window others)
    (let (yank-action)
      (if replybuffer
! 	(setq yank-action (list 'insert-buffer replybuffer)))
      (setq others (cons (cons "cc" cc) others))
      (setq others (cons (cons "in-reply-to" in-reply-to) others))
      (if same-window
--- 3222,3244 ----
  \f
  ;;;; *** Rmail Mailing Commands ***
  
+ ;; If full headers are visible, don't yank the leading From line.
+ ;; Eg supercite complains (but it's not clear if it should or not).
+ ;; http://lists.gnu.org/archive/html/emacs-devel/2009-02/msg00691.html
+ (defun rmail-reply-insert-buffer (buffer)
+   "Like `insert-buffer', but skips the leading From line, if present."
+   (insert-buffer-substring buffer (with-current-buffer buffer
+ 				    (save-excursion
+ 				      (goto-char (point-min))
+ 				      (if (looking-at "^From ")
+ 					  (forward-line 1))
+ 				      (point)))))
+ 
  (defun rmail-start-mail (&optional noerase to subject in-reply-to cc
  				   replybuffer sendactions same-window others)
    (let (yank-action)
      (if replybuffer
! 	(setq yank-action (list 'rmail-reply-insert-buffer replybuffer)))
      (setq others (cons (cons "cc" cc) others))
      (setq others (cons (cons "in-reply-to" in-reply-to) others))
      (if same-window

Re: rmail-toggle-header problem

[Kenichi Handa]

In article <1sbpsyf9y4.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> I'm not sure that yanking from the full headers makes a lot of sense,
> though. Eg it includes the X-RMAIL headers in the yank. Would you ever
> want to include the full headers (all the Received: etc) in a reply?

The reason of toggling is just to see the full headers.  I
don't intend to yank the full headers when I type r to
reply, and type C-c C-y to yank.  Actually supercite deletes
all headers.  If I really want to put the original full
headers in the reply mail, I'll copy them from RMAIL buffer.

> Separately, I also don't know whether supercite should be changed as
> was suggested.

I don't mind how the problem is fixed, but with your patch,
I get the error "Marker does not point anywhere" when I type
C-c C-y.

---
Kenichi Handa
handa@m17n.org

Re: rmail-toggle-header problem

[Glenn Morris]

Kenichi Handa wrote:

> The reason of toggling is just to see the full headers. 

Understood.

>  I don't intend to yank the full headers when I type r to reply, and
> type C-c C-y to yank. Actually supercite deletes all headers.

(depends on what supercite options you use)

Rmail should behave sensibly when supercite is not used.

So should it not yank the headers at all? Should it always yank the
"condensed" headers? Should it yank the headers as displayed (the
current behaviour)? Should it exclude "X-RMAIL"? Etc...

I have no opinion, I'm wondering what Rmail users want.

If they don't care, then just changing supercite is fine.

>> Separately, I also don't know whether supercite should be changed as
>> was suggested.
>
> I don't mind how the problem is fixed, but with your patch,
> I get the error "Marker does not point anywhere" when I type
> C-c C-y.

Hmph. insert-buffer pushes a mark, whilst insert-buffer-substring does
not.


*** rmail.el	19 Feb 2009 03:30:41 -0000	1.510
--- rmail.el	20 Feb 2009 02:03:17 -0000
***************
*** 3222,3232 ****
  \f
  ;;;; *** Rmail Mailing Commands ***
  
  (defun rmail-start-mail (&optional noerase to subject in-reply-to cc
  				   replybuffer sendactions same-window others)
    (let (yank-action)
      (if replybuffer
! 	(setq yank-action (list 'insert-buffer replybuffer)))
      (setq others (cons (cons "cc" cc) others))
      (setq others (cons (cons "in-reply-to" in-reply-to) others))
      (if same-window
--- 3222,3248 ----
  \f
  ;;;; *** Rmail Mailing Commands ***
  
+ ;; If full headers are visible, don't yank the leading From line.
+ ;; Eg supercite complains (but it's not clear if it should or not).
+ ;; http://lists.gnu.org/archive/html/emacs-devel/2009-02/msg00691.html
+ (defun rmail-reply-insert-buffer (buffer)
+   "Like `insert-buffer', but skips the leading From line, if present."
+   (push-mark
+    (save-excursion
+      (insert-buffer-substring buffer (with-current-buffer buffer
+ 				       (save-excursion
+ 					 (goto-char (point-min))
+ 					 (if (looking-at "^From ")
+ 					     (forward-line 1))
+ 					 (point))))
+      (point)))
+   nil)
+ 
  (defun rmail-start-mail (&optional noerase to subject in-reply-to cc
  				   replybuffer sendactions same-window others)
    (let (yank-action)
      (if replybuffer
! 	(setq yank-action (list 'rmail-reply-insert-buffer replybuffer)))
      (setq others (cons (cons "cc" cc) others))
      (setq others (cons (cons "in-reply-to" in-reply-to) others))
      (if same-window

Re: rmail-toggle-header problem

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 19 Feb 2009 21:12:05 -0500
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> So should it not yank the headers at all? Should it always yank the
> "condensed" headers? Should it yank the headers as displayed (the
> current behaviour)? Should it exclude "X-RMAIL"? Etc...
> 
> I have no opinion, I'm wondering what Rmail users want.

I vote for the current behavior.  Wrt the "X-RMAIL" header (or any
other headers added by Rmail), I don't care either way, although the
pre-mbox Rmail does copy the X-Coding-System header added by Rmail.

Re: rmail-toggle-header problem

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Fri, 20 Feb 2009 10:35:18 +0900
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> In article <1sbpsyf9y4.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:
> 
> > I'm not sure that yanking from the full headers makes a lot of sense,
> > though. Eg it includes the X-RMAIL headers in the yank. Would you ever
> > want to include the full headers (all the Received: etc) in a reply?
> 
> The reason of toggling is just to see the full headers.  I
> don't intend to yank the full headers when I type r to
> reply, and type C-c C-y to yank.

But the original pre-mbox Rmail would always yank the full headers
when you did that after expanding the headers with
rmail-toggle-header.  And I find that very convenient, because
sometimes I do need to cite all the headers of a message.  An
important case in point is when I'm talking to some sysadmin about a
problem in mail transport and want to show them a message as evidence.

> If I really want to put the original full
> headers in the reply mail, I'll copy them from RMAIL buffer.

This goes both ways: you could as easily delete them after they are
copied.

> I don't mind how the problem is fixed, but with your patch,
> I get the error "Marker does not point anywhere" when I type
> C-c C-y.

Obviously, the bug should be fixed, but please do not kill the feature
whereby C-c C-y copies the full headers.

Re: rmail-toggle-header problem

[Kenichi Handa]

In article <u3ae9v7e7.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@m17n.org>
> > Date: Fri, 20 Feb 2009 10:35:18 +0900
> > Cc: rms@gnu.org, emacs-devel@gnu.org
> > 
> > In article <1sbpsyf9y4.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:
> > 
> > > I'm not sure that yanking from the full headers makes a lot of sense,
> > > though. Eg it includes the X-RMAIL headers in the yank. Would you ever
> > > want to include the full headers (all the Received: etc) in a reply?
> > 
> > The reason of toggling is just to see the full headers.  I
> > don't intend to yank the full headers when I type r to
> > reply, and type C-c C-y to yank.

> But the original pre-mbox Rmail would always yank the full headers
> when you did that after expanding the headers with
> rmail-toggle-header.

I know.  As I wrote before, I'm using supercite, and with
these customizations:

 '(sc-auto-fill-region-p nil)
 '(sc-citation-delimiter-regexp "[^-][>]+")
 '(sc-citation-leader "")
 '(sc-nested-citation-p t)
 '(sc-preferred-header-style 2)
 '(sc-reference-tag-string "")

all headers are deleted by supercite.

> > I don't mind how the problem is fixed, but with your patch,
> > I get the error "Marker does not point anywhere" when I type
> > C-c C-y.

> Obviously, the bug should be fixed, but please do not kill the feature
> whereby C-c C-y copies the full headers.

I'm not proposing to kill that feature.

---
Kenichi Handa
handa@m17n.org

Re: rmail-toggle-header problem

[Richard M Stallman]

    I'm not sure that yanking from the full headers makes a lot of sense,
    though. Eg it includes the X-RMAIL headers in the yank. Would you ever
    want to include the full headers (all the Received: etc) in a reply?

I doubt it, but this combination ought to do what is natural in the
circumstances, which is to yank the headers that are visible.
To do otherwise would require artificially filtering them
in a second place.

 if the user asks for it, we may as well do what he
asked for.

Re: rmail-toggle-header problem

[Chetan Pandya]

> I'm not sure that yanking from the full headers makes a lot of sense,
>     though. Eg it includes the X-RMAIL headers in the yank. Would you ever
>     want to include the full headers (all the Received: etc) in a reply?
> 
> I doubt it, but this combination ought to do what is natural in the
> circumstances, which is to yank the headers that are visible.
> To do otherwise would require artificially filtering them in second place.
> 
>  if the user asks for it, we may as well do what he asked for.

Looking at all of the responses so far, I don't see any original headers as part of the reply.  I wonder if it is because noone wants them or because they are not provided by the MUA.

Assuming it is the former, would it not make more sense to make that as the default? It is always possible to copy whatever headers that are deemed necessary, but I suspect that isn't a very common operation.

If all headers are provided as default, it just increases the effort needed to trim it down and I am sure not everybody is interested in the full headers of the original message.

Re: rmail-toggle-header problem

[Stephen J. Turnbull]

Chetan Pandya writes:

 > Assuming it is [the case that users prefer only a small set of
 > headers to be yanked], would it not make more sense to make that as
 > the default? It is always possible to copy whatever headers that
 > are deemed necessary, but I suspect that isn't a very common
 > operation.

That *is* the default and will continue to be the default under all
schemes proposed so far, in the following sense.

Users rarely look at the non-author headers.  So yanking the displayed
headers does what you want by "default".  (If you want more control,
use supercite.)

The exception is when there is a problem with the *mail system*.  In
that case, they toggle the headers to full display, and in that case,
they are quite likely to want to forward *all* headers to a mail
admin.  It is unlikely that somebody who has toggled full-display will
fail to notice that, and if they do, recovery is just C-x k RET yes
RET C-t R.  (Not terribly short, but shorter and more accurate than
trying clean headers by hand.  BTW, forgive me if I got the keystrokes
wrong, those are the VM equivalents but I think they're the same in
Rmail.)

Nobody has proposed that all headers be included all the time as far
as I can see.

Finally, copying all headers is tedious and error-prone, which is
exactly what you don't want when you are composing a problem report.
I conclude that unless you want to provide a separate facility to
configure the yanked headers, yanking exactly the displayed headers is
the best possible scheme.

Re: rmail-toggle-header problem

[Chetan Pandya]

> I'm not sure that yanking from the full headers makes a lot of sense,
>     though. Eg it includes the X-RMAIL headers in the yank. Would you ever
>     want to include the full headers (all the Received: etc) in a reply?
> 
> I doubt it, but this combination ought to do what is natural in the
> circumstances, which is to yank the headers that are visible.
> To do otherwise would require artificially filtering them in a second place.
> 
>  if the user asks for it, we may as well do what he asked for.

Personally, I don't find it terribly important.  Just as it is possible to trim the message content to reply only a part of the mail, it would be possible to remove the headers as well, if not required.

I am also in favor of continuity with existing behaviour, unless there is a good reason not to.

Chetan

Re: rmail-toggle-header problem

[Stefan Monnier]

> I am also in favor of continuity with existing behaviour, unless there
> is a good reason not to.

More to the point, now is not the time to change the behavior of Rmail.
We're in feature-freeze, or even in pretest, and we're just trying to
get Rmail back to its previous featureset.

Improvements will have to wait for after-23.1.


        Stefan

Re: rmail-toggle-header problem

[Glenn Morris]

Richard M Stallman wrote:

>  if the user asks for it, we may as well do what he asked for.

OK, this seems clear. I've installed a supercite fix, and left rmail alone.

Re: rmail-toggle-header problem

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 20 Feb 2009 22:18:32 -0500
> Cc: emacs-devel@gnu.org, handa@m17n.org
> 
> Richard M Stallman wrote:
> 
> >  if the user asks for it, we may as well do what he asked for.
> 
> OK, this seems clear. I've installed a supercite fix, and left rmail alone.

Thank you.

Re: rmail-toggle-header problem

[Alfred M. Szmidt]

   But the original pre-mbox Rmail would always yank the full headers
   when you did that after expanding the headers with
   rmail-toggle-header.  And I find that very convenient, because
   sometimes I do need to cite all the headers of a message.  An
   important case in point is when I'm talking to some sysadmin about
   a problem in mail transport and want to show them a message as
   evidence.

Agreed, it is also intuitive.  rmail will yank what it shown, this
makes very much sense.

Re: rmail-toggle-header problem

[Xavier Maillard]

      But the original pre-mbox Rmail would always yank the full headers
      when you did that after expanding the headers with
      rmail-toggle-header.  And I find that very convenient, because
      sometimes I do need to cite all the headers of a message.  An
      important case in point is when I'm talking to some sysadmin about
      a problem in mail transport and want to show them a message as
      evidence.

   Agreed, it is also intuitive.  rmail will yank what it shown, this
   makes very much sense.

+1. I use that pretty often when sending abuse messages (it
happends a dozen of times a week).

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org