unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
To: pandyacus@sbcglobal.net
Cc: emacs-devel@gnu.org
Subject: Re: rmail-toggle-header problem
Date: Sat, 21 Feb 2009 11:34:23 +0900	[thread overview]
Message-ID: <87ljs05xhs.fsf@xemacs.org> (raw)
In-Reply-To: <455812.70516.qm@web83203.mail.mud.yahoo.com>

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.




  reply	other threads:[~2009-02-21  2:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-18  2:26 rmail-toggle-header problem Kenichi Handa
2009-02-18  5:29 ` Glenn Morris
2009-02-18  6:37   ` Kenichi Handa
2009-02-18 12:10 ` Richard M Stallman
2009-02-19 20:28   ` Glenn Morris
2009-02-20  1:35     ` Kenichi Handa
2009-02-20  2:12       ` Glenn Morris
2009-02-20  8:34         ` Eli Zaretskii
2009-02-20  8:29       ` Eli Zaretskii
2009-02-20 12:59         ` Kenichi Handa
2009-02-20 13:30     ` Richard M Stallman
2009-02-20 22:21       ` Chetan Pandya
2009-02-21  2:34         ` Stephen J. Turnbull [this message]
2009-02-21  1:18       ` Chetan Pandya
2009-02-21  2:21         ` Stefan Monnier
2009-02-21  3:18       ` Glenn Morris
2009-02-21  9:12         ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2009-02-20  9:35 Alfred M. Szmidt
2009-02-22  9:25 Xavier Maillard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ljs05xhs.fsf@xemacs.org \
    --to=turnbull@sk.tsukuba.ac.jp \
    --cc=emacs-devel@gnu.org \
    --cc=pandyacus@sbcglobal.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).