Tamo, I have some comments on your manual patch. :)
On Fri, Feb 04, 2005 at 06:03:06PM +0900, Tamotsu Takahashi wrote:
> { "move", DT_QUAD, R_NONE, OPT_MOVE, M_ASKNO },
> /*
> ** .pp
> - ** Controls whether you will be asked to confirm moving read messages
> + ** Controls whether or not Mutt will move read messages
For quad options, this change is definitely right [that is, if set,
the action will be performed, not prompted]. However...
> ** from your spool mailbox to your ``$$mbox'' mailbox, or as a result of
> - ** a ``$mbox-hook'' command.
> + ** a ``$mbox-hook'' command. You will be asked to confirm moving
> + ** them if this option is set to either \fIask-yes\fP or \fIask-no\fP.
...personally, I find repeating this information about what ask-yes
and ask-no for each quad option to be unnecessary and tedious. Quad
option behavior is explained clearly in section 3.23, and it should be
clear that ask-* cause a prompt where a yes or no would not. This
information should not be repeated in every single quad option manual
entry.
> ** Controls whether or not messages are saved in the ``$$postponed''
> - ** mailbox when you elect not to send immediately.
> + ** mailbox when you select not to send immediately.
Here, "elect" is the right choice. It means, "to choose, to decide,"
whereas "select" means "to chose from a set of presented options." At
the specific point in time when this variable is relevant, we have not
selected anything, because mutt has not presented us any menu of
options to select from... We have simply told mutt to quit sending
the message we're working on. That is, (q)uit is a command, not a
menu selection.
> { "print", DT_QUAD, R_NONE, OPT_PRINT, M_ASKNO },
> /*
> ** .pp
> - ** Controls whether or not Mutt asks for confirmation before printing.
> + ** When set to \fIask-yes\fP or \fIask-no\fP, Mutt asks for confirmation
> before printing.
> ** This is useful for people (like me) who accidentally hit ``p'' often.
> */
It seems unclear what mutt does if print is set or unset... The
provided description only tells what it does if the value is ask-*.
The obvious is that if set to no, mutt will simply ignore the print
command, effectively disabling printing. This may seem confusing to a
new user, because it seems (at least to me) that this is really
strange behavior. I think that needs to be spelled out, where again,
the behavior of ask-* should be well understood.
FWIW, it also seems to me that this need not be a quad at all, since a value
of no is not useful, and a value of yes is not needed if it were a
boolean such as "prompt-print" instead. But I guess that doesn't give
you the choice of default value...
> { "recall", DT_QUAD, R_NONE, OPT_RECALL, M_ASKYES },
[SNIP]
> ** Setting this variable to ``yes'' is not generally useful, and thus not
> ** recommended.
If setting recall=yes is not useful, then this also seems to me like
it should not be a quad option, but a boolean -> "prompt_recall",
except for the same caveat above.
> @@ -2174,7 +2176,8 @@
> { "reply_to", DT_QUAD, R_NONE, OPT_REPLYTO, M_ASKYES },
> /*
> ** .pp
> - ** If set, Mutt will ask you if you want to use the address listed in the
> + ** If set to \fIask-yes\fP or \fIask-no\fP, Mutt will ask you if you want
> + ** to use the address listed in the
Again, I think it's clear what ask-yes and ask-no are used for. I
think this should read as follows:
If set, when replying to a message, Mutt will use the address listed
in the Reply-to: header as the recipient of the reply. If unset,
Mutt will use the address in the From: header instead.
> @@ -2567,7 +2570,7 @@
> ** .pp
> ** where \fIsequence_char\fP is a character from the table above, and
> ** \fIoptional_string\fP is the string you would like printed if
> - ** \fIstatus_char\fP is nonzero. \fIoptional_string\fP \fBmay\fP contain
> + ** \fIsequence_char\fP is nonzero. \fIoptional_string\fP \fBmay\fP contain
> ** other sequence as well as normal text, but you may \fBnot\fP nest
> ** optional strings.
This should read, "may contain another sequence," or, "may contain
other sequences." As written, there is a singular/plural mismatch.
After reading the relevant section, I believe the second choice is the
better one.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgphGiFKVV350.pgp
Description: PGP signature