[notmuch] [PATCH -V3 1/2] notmuch-reply: Add support for replying only to sender
Michal Sojka
sojkam1 at fel.cvut.cz
Thu Mar 11 04:45:45 PST 2010
Hi,
On Wed, 10 Mar 2010, Aneesh Kumar K.V wrote:
> From: Aneesh Kumar K.V <aneesh.kumar at gmail.com>
>
> This patch add --recipient=all|sender option
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar at gmail.com>
> ---
> notmuch-client.h | 2 +
> notmuch-reply.c | 55 ++++++++++++++++++++++++++++++++++++++++-------------
> 2 files changed, 43 insertions(+), 14 deletions(-)
>
> diff --git a/notmuch-client.h b/notmuch-client.h
> index c80b39c..26fdb4a 100644
> --- a/notmuch-client.h
> +++ b/notmuch-client.h
> @@ -70,6 +70,8 @@
> #define STRNCMP_LITERAL(var, literal) \
> strncmp ((var), (literal), sizeof (literal) - 1)
>
> +#define NOTMUCH_REPLY_ALL 0x1
> +#define NOTMUCH_REPLY_SENDER_ONLY 0x2
Why not to define this as enum? When I see a definition like this
it reminds me bit flags which can be used together e.g.
(NOTMUCH_REPLY_ALL | NOTMUCH_REPLY_SENDER_ONLY).
This has obviously no sense here.
> static inline void
> chomp_newline (char *str)
> {
> diff --git a/notmuch-reply.c b/notmuch-reply.c
> index 6c15536..e8a0820 100644
> --- a/notmuch-reply.c
> +++ b/notmuch-reply.c
> @@ -232,20 +232,37 @@ reply_to_header_is_redundant (notmuch_message_t *message)
> static const char *
> add_recipients_from_message (GMimeMessage *reply,
> notmuch_config_t *config,
> - notmuch_message_t *message)
> + notmuch_message_t *message,
> + int reply_options)
> {
> - struct {
> + struct reply_to_map {
> const char *header;
> const char *fallback;
> GMimeRecipientType recipient_type;
> - } reply_to_map[] = {
> + } ;
> + const char *from_addr = NULL;
> + unsigned int i;
> + struct reply_to_map *reply_to_map;
> +
> + struct reply_to_map reply_to_map_all[] = {
> { "reply-to", "from", GMIME_RECIPIENT_TYPE_TO },
> { "to", NULL, GMIME_RECIPIENT_TYPE_TO },
> { "cc", NULL, GMIME_RECIPIENT_TYPE_CC },
> - { "bcc", NULL, GMIME_RECIPIENT_TYPE_BCC }
> + { "bcc", NULL, GMIME_RECIPIENT_TYPE_BCC },
> + { NULL, NULL, 0 }
> };
> - const char *from_addr = NULL;
> - unsigned int i;
> +
> + /* we try from first and then reply-to */
> + struct reply_to_map reply_to_map_sender[] = {
> + { "from", "reply-to", GMIME_RECIPIENT_TYPE_TO },
> + { NULL, NULL, 0 }
> + };
I'm not sure whether an e-mail without From: is a valid e-mail. If not,
you would never use "reply-to" header. Also, given the link below
(http://www.unicom.com/pw/reply-to-harmful.html), this will not behave
as Carl likes :). Finally, don't forget that reply_to_map can be
modified in add_recipients_from_message().
I missed your original patch so I implement this for myself in a less
intrusive way (see
id:1267464588-21050-1-git-send-email-sojkam1 at fel.cvut.cz). What I like
at your approach is that --recipient option can have several values. I
think it would be useful to have three possible values of this option:
"all", "sender" and something like "reply-to-or-sender". The latter
option would cause using of Reply-to: header event if it is found as
redundant by reply_to_header_is_redundant(). I find this useful for
several private mailing lists I use.
-Michal
> +
> + if (reply_options == NOTMUCH_REPLY_SENDER_ONLY) {
> + reply_to_map = reply_to_map_sender;
> + } else {
> + reply_to_map = reply_to_map_all;
> + }
>
> /* Some mailing lists munge the Reply-To header despite it being A Bad
> * Thing, see http://www.unicom.com/pw/reply-to-harmful.html
More information about the notmuch
mailing list