[PATCH] compose to sender

[Brian Medley]

Hi,

I have created a patch that starts a new message to the sender of
the currently selected message. In addition, I think I updated
The Manual correctly.

Suggestions/Thoughts/Criticism are welcome.

[Fabian Groffen]

Post by Brian Medley
Hi,
I have created a patch that starts a new message to the sender of
the currently selected message. In addition, I think I updated
The Manual correctly.
Suggestions/Thoughts/Criticism are welcome.

That is a great feature I've thought about many times. Is it also
possible to tag a few messages and then compose a message directed to
the senders of the tagged messages?

How about the "To:" prompt of "m" (normal compose message) to default to
the sender of the message currently selected, like for instance mailbox
switching now also suggests a value, but erases it on the first
keystroke?

[Brian Medley]

On Fri, Feb 29, 2008 at 08:54:46AM +0100, Fabian Groffen wrote:

No,

I don't think that currently works; I'll work on it.

Thanks for the idea!!

Post by Fabian Groffen

Post by Brian Medley
Hi,
I have created a patch that starts a new message to the sender of
the currently selected message. In addition, I think I updated
The Manual correctly.
Suggestions/Thoughts/Criticism are welcome.

That is a great feature I've thought about many times. Is it also
possible to tag a few messages and then compose a message directed to
the senders of the tagged messages?
How about the "To:" prompt of "m" (normal compose message) to default to
the sender of the message currently selected, like for instance mailbox
switching now also suggests a value, but erases it on the first
keystroke?
--
Fabian Groffen
Gentoo on a different level

[Gary Johnson]

Post by Brian Medley
Hi,
I have created a patch that starts a new message to the sender of
the currently selected message. In addition, I think I updated
The Manual correctly.
Suggestions/Thoughts/Criticism are welcome.

Terrific! I've wanted this on a number of occasions but haven't had
time to attempt a patch myself. The patch applied fine except for
the patch to manual.xml.head, which I don't seem to have:

can't find file to patch at input line 58
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r -u mutt-1.5.17/doc/manual.xml.head mutt-1.5.17-compose/doc/manual.xml.head
|--- mutt-1.5.17/doc/manual.xml.head 2007-11-01 14:02:58.000000000 -0500
|+++ mutt-1.5.17-compose/doc/manual.xml.head 2008-02-28 22:52:09.000000000 -0600
--------------------------

It built and seems to work fine, though. Thank you!

Regards,
Gary

[Sébastien Hinderer]

Hi,

One related question: does mutt already offer the possibility to
resend(bounce?) a mesage exactly to those addresses it has already been
sent to ?
This would be useful, for instance, in situations where the message
could not be sent because of, say, a problem with finding a smarthost to
send the message.
Cheers,
Sébastien.

[Thomas Roessler]

Post by Sébastien Hinderer
One related question: does mutt already offer the possibility to
resend(bounce?) a mesage exactly to those addresses it has already been
sent to ?
This would be useful, for instance, in situations where the message
could not be sent because of, say, a problem with finding a smarthost to
send the message.

resend-message

bound to M-e by default, I seem to recall.

[Vincent Lefevre]

Post by Thomas Roessler

Post by Sébastien Hinderer
This would be useful, for instance, in situations where the
message could not be sent because of, say, a problem with finding
a smarthost to send the message.

resend-message
bound to M-e by default, I seem to recall.

But is there a way to automatically remove some headers, such as
"Delivered-To:"?

[Thomas Roessler]

Post by Vincent Lefevre
But is there a way to automatically remove some headers, such as
"Delivered-To:"?

If I remember correctly, it does remove some headers. Might be that
some more should be dropped.

[Vincent Lefevre]

Post by Thomas Roessler

Post by Vincent Lefevre
But is there a way to automatically remove some headers, such as
"Delivered-To:"?

If I remember correctly, it does remove some headers. Might be that
some more should be dropped.

If fact, the code is buggy: it doesn't keep the ignored headers.

If I understand correctly, header dropping is in mutt_parse_rfc822_line
in parse.c, where there's a difference between *some* standard headers
and other headers. The Received headers are taken into account in the
standard part, but don't have the "matched = 1;" (probably because only
the date of the first Received header is kept, i.e. very partial info);
so, they are not dropped either in resend-message if one doesn't ignore
any header! The code seriously lack comments.

[William Yardley]

Post by Brian Medley
I have created a patch that starts a new message to the sender of
the currently selected message. In addition, I think I updated
The Manual correctly.

Would be great if there were also a 'compose to list' option. Not sure
if it would be better to have the function compose to the list if the
message is to a subscribed list, or to have a different command for
"compose to list".

w

[Thomas Roessler]

Post by William Yardley
Would be great if there were also a 'compose to list' option. Not
sure if it would be better to have the function compose to the
list if the message is to a subscribed list, or to have a
different command for "compose to list".

Why isn't list-reply close enough for that?

[Rado S]

=- Thomas Roessler wrote on Fri 29.Feb'08 at 9:32:19 +0100 -=

Post by Thomas Roessler

Post by William Yardley
Would be great if there were also a 'compose to list' option.
Not sure if it would be better to have the function compose to
the list if the message is to a subscribed list, or to have a
different command for "compose to list".

Why isn't list-reply close enough for that?

Because you don't want to reply to an existing thread but start a
new one.
I have aliases for that. ;)

[Patrick Shanahan]

Post by Rado S
=- Thomas Roessler wrote on Fri 29.Feb'08 at 9:32:19 +0100 -=

Post by Thomas Roessler

Post by William Yardley
Would be great if there were also a 'compose to list' option.
Not sure if it would be better to have the function compose to
the list if the message is to a subscribed list, or to have a
different command for "compose to list".

Why isn't list-reply close enough for that?

Because you don't want to reply to an existing thread but start a
new one.
I have aliases for that. ;)

And you will provide an example ?? :^)

[Gary Johnson]

Post by Patrick Shanahan

Post by Rado S
=- Thomas Roessler wrote on Fri 29.Feb'08 at 9:32:19 +0100 -=

Post by Thomas Roessler

Post by William Yardley
Would be great if there were also a 'compose to list' option.
Not sure if it would be better to have the function compose to
the list if the message is to a subscribed list, or to have a
different command for "compose to list".

Why isn't list-reply close enough for that?

Because you don't want to reply to an existing thread but start a
new one.
I have aliases for that. ;)

And you will provide an example ?? :^)

Here's an example of what I use, one for each list to which I post.

folder-hook +Incoming/mutt-dev \
'macro index M "<mail>mutt-dev^M^M" "mail to list"'
folder-hook +Incoming/mutt-users \
'macro index M "<mail>mutt-users^M^M" "mail to list"'

The second ^M in each of those skips the "Cc:" prompt.

HTH,
Gary

[Brian Salter-Duke]

Post by Gary Johnson

Post by Patrick Shanahan

Post by Rado S
=- Thomas Roessler wrote on Fri 29.Feb'08 at 9:32:19 +0100 -=

Post by Thomas Roessler

Post by William Yardley
Would be great if there were also a 'compose to list' option.
Not sure if it would be better to have the function compose to
the list if the message is to a subscribed list, or to have a
different command for "compose to list".

Why isn't list-reply close enough for that?

Because you don't want to reply to an existing thread but start a
new one.
I have aliases for that. ;)

And you will provide an example ?? :^)

Here's an example of what I use, one for each list to which I post.
folder-hook +Incoming/mutt-dev \
'macro index M "<mail>mutt-dev^M^M" "mail to list"'
folder-hook +Incoming/mutt-users \
'macro index M "<mail>mutt-users^M^M" "mail to list"'
The second ^M in each of those skips the "Cc:" prompt.
HTH,
Gary

Gary, that is very usefull. However is there a way to add something so
it does not say "No Subject: Abort? ([Yes]/No"? Maybe set abort_nosubject
for this folder to ask=no and add <enter> somewhere. Any thoughts?

Brian.

[Gary Johnson]

Post by Brian Salter-Duke

Post by Gary Johnson

Post by Patrick Shanahan

Post by Rado S
=- Thomas Roessler wrote on Fri 29.Feb'08 at 9:32:19 +0100 -=

Post by Thomas Roessler

Post by William Yardley
Would be great if there were also a 'compose to list' option.
Not sure if it would be better to have the function compose to
the list if the message is to a subscribed list, or to have a
different command for "compose to list".

Why isn't list-reply close enough for that?

Because you don't want to reply to an existing thread but start a
new one.
I have aliases for that. ;)

And you will provide an example ?? :^)

Here's an example of what I use, one for each list to which I post.
folder-hook +Incoming/mutt-dev \
'macro index M "<mail>mutt-dev^M^M" "mail to list"'
folder-hook +Incoming/mutt-users \
'macro index M "<mail>mutt-users^M^M" "mail to list"'
The second ^M in each of those skips the "Cc:" prompt.
HTH,
Gary

Gary, that is very usefull. However is there a way to add something so
it does not say "No Subject: Abort? ([Yes]/No"? Maybe set abort_nosubject
for this folder to ask=no and add <enter> somewhere. Any thoughts?

I forgot to mention that. A consequence of excessive multitasking,
I think. At least that's my excuse.

I have mutt configured so that when I initiate a message, must first
asks for "To:", then "Cc:", then "Subject:", then enters the editor.
I think that's a consequence of

set askcc

in my muttrc.

If you are getting that message, your mutt is probably not asking
"Cc:" and my macro is answering "Subject:" with Enter. Unless you
want to be asked "Cc:" all the time, you can just remove one of the
^M in the macro.

HTH,
Gary

[Brian Salter-Duke]

Post by Gary Johnson

Post by Brian Salter-Duke

Post by Gary Johnson

Post by Patrick Shanahan

Post by Rado S
=- Thomas Roessler wrote on Fri 29.Feb'08 at 9:32:19 +0100 -=

Post by Thomas Roessler

Post by William Yardley
Would be great if there were also a 'compose to list' option.
Not sure if it would be better to have the function compose to
the list if the message is to a subscribed list, or to have a
different command for "compose to list".

Why isn't list-reply close enough for that?

Because you don't want to reply to an existing thread but start a
new one.
I have aliases for that. ;)

And you will provide an example ?? :^)

Here's an example of what I use, one for each list to which I post.
folder-hook +Incoming/mutt-dev \
'macro index M "<mail>mutt-dev^M^M" "mail to list"'
folder-hook +Incoming/mutt-users \
'macro index M "<mail>mutt-users^M^M" "mail to list"'
The second ^M in each of those skips the "Cc:" prompt.
HTH,
Gary

Gary, that is very usefull. However is there a way to add something so
it does not say "No Subject: Abort? ([Yes]/No"? Maybe set abort_nosubject
for this folder to ask=no and add <enter> somewhere. Any thoughts?

I forgot to mention that. A consequence of excessive multitasking,
I think. At least that's my excuse.
I have mutt configured so that when I initiate a message, must first
asks for "To:", then "Cc:", then "Subject:", then enters the editor.
I think that's a consequence of
set askcc
in my muttrc.
If you are getting that message, your mutt is probably not asking
"Cc:" and my macro is answering "Subject:" with Enter. Unless you
want to be asked "Cc:" all the time, you can just remove one of the
^M in the macro.

I get the headers as part of the message to edit, I have always done
this and I think it comes from setting edit_header. I am happy to add
the subject there. I would prefer to not have to hit enter when

No Subject: Abort? ([Yes]/No

comes up. I have:-

folder-hook . set abort_nosubject=ask-yes
folder-hook mutt.dev set abort_nosubject=ask-no
folder-hook mutt.dev \
'macro index M "<mail>mutt-dev^M^M" "mail to list"<enter>'

It asks the abort and demands the response whether I have the <enter>
there or not. Maybe I have it in the wrong place.

Cheers, Brian.

Post by Gary Johnson
HTH,
Gary

[Breen Mullins]

Post by Brian Salter-Duke
I get the headers as part of the message to edit, I have always done
this and I think it comes from setting edit_header. I am happy to add
the subject there. I would prefer to not have to hit enter when
No Subject: Abort? ([Yes]/No
comes up. I have:-
folder-hook . set abort_nosubject=ask-yes
folder-hook mutt.dev set abort_nosubject=ask-no
folder-hook mutt.dev \
'macro index M "<mail>mutt-dev^M^M" "mail to list"<enter>'

Your setting for abort_nosubject is telling it to ask you. It's a
quadoption -- you need to set abort_nosubject to 'no' and it should
stop nagging you.

Or am I completely misunderstanding you?

[Brian Salter-Duke]

Post by Brian Salter-Duke
I get the headers as part of the message to edit, I have always done
this and I think it comes from setting edit_header. I am happy to add
the subject there. I would prefer to not have to hit enter when
No Subject: Abort? ([Yes]/No
comes up. I have:-
folder-hook . set abort_nosubject=ask-yes
folder-hook mutt.dev set abort_nosubject=ask-no
folder-hook mutt.dev \
'macro index M "<mail>mutt-dev^M^M" "mail to list"<enter>'

Your setting for abort_nosubject is telling it to ask you. It's a quadoption
-- you need to set abort_nosubject to 'no' and it should
stop nagging you.
Or am I completely misunderstanding you?

Duh. No you are not. I always had ask-yes, so I just changed it to
ask-no. Of course it should be just no and then it works fine. Must have
been too early this morning. Many thanks.

Brian.

--
Breen Mullins
Menlo Park, California

[Rado S]

=- Patrick Shanahan wrote on Sun 2.Mar'08 at 15:52:13 -0500 -=

Post by Patrick Shanahan

Post by Rado S

Post by Thomas Roessler

Post by William Yardley
Would be great if there were also a 'compose to list'
option. Not sure if it would be better to have the function
compose to the list if the message is to a subscribed list,
or to have a different command for "compose to list".

Why isn't list-reply close enough for that?

Because you don't want to reply to an existing thread but start a
new one.
I have aliases for that. ;)

And you will provide an example ?? :^)

Gary's solution is probably closer to what you expect(ed), but mine
has no magic with it: I simply define all my MLs as "ml-..." alias
and hit 'm' as usual to start a new msg.

The proposed feature would allow for 1-click solution (beware of the
amazon patent), but Gary's does that already with the current code.

As always the struggle between adapting the code or the own setup to
suit convenience...

[Aron Griffis]

Rado S wrote: [Mon Mar 03 2008, 06:50:41AM EST]

Post by Rado S
Gary's solution is probably closer to what you expect(ed), but mine
has no magic with it: I simply define all my MLs as "ml-..." alias
and hit 'm' as usual to start a new msg.

How funny, I do exactly the same thing. I do it in m4 with:

changequote(<<,>>)

define(<<ML>>, <<
patsubst($2, <<\([^
]+\)@\([^
]+\)>>, <<
alias \1 \&
alias ml-\1 \&

Post by Rado S

)
)

then later in muttrc.in:

ML(subscribe, <<
The <<@>> is spam protection since I publish my full muttrc.in
online. This results in:

alias mutt-dev mutt-***@mutt.org
alias ml-mutt-dev mutt-***@mutt.org
subscribe mutt-dev@
send-hook '~C mutt-***@mutt.org' 'set from="Aron Griffis <...>"'

alias mutt-users mutt-***@mutt.org
alias ml-mutt-users mutt-***@mutt.org
subscribe mutt-users@
send-hook '~C mutt-***@mutt.org' 'set from="Aron Griffis <...>"'

Aron

[Gary Johnson]

Post by Aron Griffis
Rado S wrote: [Mon Mar 03 2008, 06:50:41AM EST]

Post by Rado S
Gary's solution is probably closer to what you expect(ed), but mine
has no magic with it: I simply define all my MLs as "ml-..." alias
and hit 'm' as usual to start a new msg.

changequote(<<,>>)
define(<<ML>>, <<
patsubst($2, <<\([^
]+\)>>, <<
alias \1 \&
alias ml-\1 \&

Post by Rado S

)
)

ML(subscribe, <<

Nice.

This reminded me of something else I omitted from my previous
replies: I also have

alias mutt-dev mutt-***@mutt.org
alias mutt-users mutt-***@mutt.org

in my aliases file. Without those, the addresses in my M macros
won't be correctly expanded.

Regards,
Gary

[Alain Bench]

Hello Aron,
Note that this pre-1.5.6-like syntax is guaranteed to provide false
positives. One should now better write as strict as possible regexps:

| subscribe ^mutt-***@mutt\\.org$
| send-hook '~C ^mutt-***@mutt\.org$'


Bye! Alain.

[Aron Griffis]

Hi Alain,

Alain Bench wrote: [Tue Mar 04 2008, 12:38:12PM EST]

Post by Alain Bench
Note that this pre-1.5.6-like syntax is guaranteed to provide false
positives.

Well, I know it's loose, but will it cause a false positive in
any common case?

Aron

[Alain Bench]

will it cause a false positive in any common case?

A quick search on 16668 mails here found 424 false positives.
Example the message at origin of this thread is sent by Brian Medley
<bpm-lists-mutt-dev AT bmedley DOT org>. It's not uncommon to use such
specific aliases for mailing list subscriptions, Bill and Kyle are also
good examples.

I could not find any false positive for your specific send-hook
pattern, but already encountred several times various nasty problems
(and even bug reports) due to such lax non-anchored regexps. That's why
I always advice to write the strictest possible regexps for a given
goal. Especially when generated automatically: Costs not so much.


Bye! Alain.

[Aron Griffis]

Alain Bench wrote: [Fri Mar 07 2008, 08:50:09AM EST]

Post by Alain Bench
A quick search on 16668 mails here found 424 false positives.
Example the message at origin of this thread is sent by Brian Medley
<bpm-lists-mutt-dev AT bmedley DOT org>. It's not uncommon to use such
specific aliases for mailing list subscriptions, Bill and Kyle are also
good examples.

Ah, good point, thanks.

Post by Alain Bench
I could not find any false positive for your specific send-hook
pattern, but already encountred several times various nasty problems
(and even bug reports) due to such lax non-anchored regexps. That's why
I always advice to write the strictest possible regexps for a given
goal. Especially when generated automatically: Costs not so much.

You're right, thanks!

[N.J. Mann]

Post by Brian Medley
I have created a patch that starts a new message to the sender of
the currently selected message. In addition, I think I updated
The Manual correctly.

Great idea.

Post by Brian Medley
Suggestions/Thoughts/Criticism are welcome.

I didn't compile without warnings for me, so I fixed that and also made
a few white space changes to match the usual Mutt style.


Cheers,
Nick.
--

[Thomas Roessler]

Post by N.J. Mann

Post by Brian Medley
I have created a patch that starts a new message to the sender
of the currently selected message. In addition, I think I
updated The Manual correctly.

Great idea.

Post by Brian Medley
Suggestions/Thoughts/Criticism are welcome.

I didn't compile without warnings for me, so I fixed that and
also made a few white space changes to match the usual Mutt
style.

So, the main differences from the usual reply function are:

- no default subject header (oh well)
- no handling of reply headers (probably a bug)
- no headers that indicate that the message is a reply

I don't think that this should be yet another function -- rather,
I'd suggest to add a quadoption to reply that controls the various
reply headers.

[Gary Johnson]

Post by Thomas Roessler

Post by N.J. Mann

Post by Brian Medley
I have created a patch that starts a new message to the sender
of the currently selected message. In addition, I think I
updated The Manual correctly.

Great idea.

Post by Brian Medley
Suggestions/Thoughts/Criticism are welcome.

I didn't compile without warnings for me, so I fixed that and
also made a few white space changes to match the usual Mutt
style.

- no default subject header (oh well)
- no handling of reply headers (probably a bug)
- no headers that indicate that the message is a reply
I don't think that this should be yet another function -- rather,
I'd suggest to add a quadoption to reply that controls the various
reply headers.

First off, that would be contrary to the way mutt handles reply
variations now. Mutt currently has separate functions for

reply
group-reply
list-reply

Secondly, I don't think of this as a variation on reply. When I use
the function, I want to send a new message to a particular person
whose address I don't have memorized, don't have an alias for and
which I'm too lazy to look up or copy, but from whom I have recently
received some other correspondence.

As you point out above, this new function creates a message having
none of the attributes of a reply. In addition to your list, the
message body does not contain a copy, quoted or not, of the original
message. This function seems to me much closer to a variation on
composing or address-selection.

A quadoption to make <reply> behave like <compose-sender> would have
to control at least four attributes of the message: To:, Subject:,
In-Reply-To:, body. That seems like an odd assortment to group
under a single quadoption, and I certainly wouldn't want to have to
answer a lot of questions just to distinguish the two ways of
creating a message.

Making this function a variation on <reply> would also make it
trigger reply-hooks, which is probably undesirable.

Regards,
Gary

[Alain Bench]

Hello Brian, and thank you for proposing this interesting feature,

I have created a patch that starts a new message to the sender of the
currently selected message.
| <compose-sender> OP_COMPOSE_SENDER "compose new message to sender"

The naming could be improved. OP_COMPOSE_SENDER works from index and
pager, while the whole OP_COMPOSE_* namespace is reserved for operations
specific to the compose menu. <compose-sender> is a very close variant
of <mail> "compose a new mail message", and the name should carry this
clearly. I would have proposed:

| <mail-sender> OP_MAIL_SENDER "compose a new message to the sender"

However I really prefer Fabian's idea about keeping the <mail>
function only, but where the "To:" prompt would optionaly default to the
current sender. Prompt using the M_CLEAR mode where anything typed
instantly replaces the default. The only concern would be interactions
with $autoedit: I'd say this mandates a $mail_defaults_to_sender
boolean, no?

Users can think of the <compose-sender> feature as a variant of
<mail> (to the selected sender), or as a variant of <reply> (without
quote, attribution, nor refs), at will. But from code POV, the <mail>
side would need less changes.


Bye! Alain.