[Mutt] #3986: send-hook for Cc and Bcc executed too late

[Mutt]

#3986: send-hook for Cc and Bcc executed too late
------------------------------+----------------------
Reporter: alahouze | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone:
Component: mutt | Version:
Keywords: send-hook my_hdr |
------------------------------+----------------------
Hi,

I have a hook to initialize Cc on new mails only:

{{{ send-hook !~Q 'my_hdr Cc: Contact Example <***@example.com>' }}}


When I create a new mail for the first time, Cc header is not initialized.

When I create a second new mail, it is.

I also have a folder hook to reset send hook (I have a multi account
configuration, each one in a separate folder). Let's say account1 for the
one I want Cc on new mails and account2 for the other one.

1. I make a new mail on account1: Cc is not initialized but should be
2. I make another new mail on account1: Cc is initialized
3. Then I make a mail on account2: Cc is initialized but should not be
4. Finally I make another new mail on account2: Cc is not initialized

It seems the hook is run after the mail edition.

I am using neomutt, so I discussed about it with flatcap on
#***@freenode who confirmed the bug for Cc and Bcc headers, and
confirmed it on upstream mutt too and so he asked me to open a new ticket
here, so here it is.

--
Ticket URL: <https://dev.mutt.org/trac/ticket/3986>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

[Mutt]

#3986: send-hook for Cc and Bcc executed too late
-----------------------+------------------------------
Reporter: alahouze | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone:
Component: mutt | Version:
Resolution: | Keywords: send-hook my_hdr
-----------------------+------------------------------

Comment (by kevin8t8):

Please see https://muttmua.gitlab.io/mutt/manual-dev.html#send-hook the
second note:

send-hook's are only executed once after getting the initial list of
recipients. Adding a recipient after replying or editing the message will
not cause any send-hook to be executed, similarly if $autoedit is set (as
then the initial list of recipients is empty). Also note that my_hdr
commands which modify recipient headers, or the message's subject, don't
have any effect on the current message when executed from a send-hook.

--
Ticket URL: <https://dev.mutt.org/trac/ticket/3986#comment:1>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

[Andras Salamon]

On 2018-01-23 15:50:38 -0000, kevin8t8 wrote:
[quoting from the manual:]

Post by Mutt
Also note that my_hdr
commands which modify recipient headers, or the message's subject, don't
have any effect on the current message when executed from a send-hook.

Is there any reasonable use case for send-hook modifying the MUA state
for _subsequent messages only_, but not the current message? There are
good _technical_ reasons due to data structures in mutt's source code,
but I can't think of any good use cases.

In fact, it seems to me that one of the most commonly desired state
changes in a mail user agent is to change the sender (From: and/or
Sender: fields), possibly also the Fcc:/Bcc:/Cc: fields, or even the
arguments to the mail submission agent, to support multiple roles from a
single mailbox. This allows sending to Alice using identity 1, sending
to Bob via identity 2, and for everyone else using the default identity.
Many mail clients support changing identities based on recipient. In
contrast, the current semantics of send-hook seems to be nudging the
user to use identities in a coarse-grained way, for instance by running
multiple mutt instances, one for each identity. However, this seems to
work best with multiple inboxes, something that seems less common
nowadays than when I started using mutt twenty years ago.

If there is a good use case for "change-state-on-subsequent-messages",
I'd appreciate someone describing it.

-- Andras Salamon ***@dns.net

[Kevin J. McCarthy]

Hi Andras,

I thought this post would generate more traffic; I'm very interested in
others opinions on this too, but I'll pipe in.

Post by Andras Salamon
Is there any reasonable use case for send-hook modifying the MUA state
for _subsequent messages only_, but not the current message? There are
good _technical_ reasons due to data structures in mutt's source code,
but I can't think of any good use cases.

Just to be clear, the send and reply hooks run after recipients (To, Cc,
Bcc) and Subject are set. So one of those hooks containing a my_hdr
command for those particular headers won't have effect for the current
message.

However, a my_hdr in these hooks setting other headers, including From,
_will_ affect the current message. Changes to config vars such as
$sendmail etc are also effective immediately.

I don't make much use of auto-recipients or subject transformation, so I
may have a blind spot here. Do people feel the parent ticket represents
a broad need that Mutt doesn't address?

[Vincent Lefevre]

Post by Kevin J. McCarthy
Hi Andras,
I thought this post would generate more traffic; I'm very interested in
others opinions on this too, but I'll pipe in.

Post by Andras Salamon
Is there any reasonable use case for send-hook modifying the MUA state
for _subsequent messages only_, but not the current message? There are
good _technical_ reasons due to data structures in mutt's source code,
but I can't think of any good use cases.

Just to be clear, the send and reply hooks run after recipients (To, Cc,
Bcc) and Subject are set. So one of those hooks containing a my_hdr
command for those particular headers won't have effect for the current
message.
However, a my_hdr in these hooks setting other headers, including From,
_will_ affect the current message. Changes to config vars such as
$sendmail etc are also effective immediately.
I don't make much use of auto-recipients or subject transformation, so I
may have a blind spot here. Do people feel the parent ticket represents
a broad need that Mutt doesn't address?

I think that it works as expected, the goal of the "my_hdr" command
not being to change a header, but to create a default one. But a new
command to modify a header for the current message might be useful,
and probably cleaner for send-hook's.

[Mutt]

#3986: send-hook for Cc and Bcc executed too late
-----------------------+------------------------------
Reporter: alahouze | Owner: mutt-dev
Type: defect | Status: closed
Priority: major | Milestone:
Component: mutt | Version:
Resolution: invalid | Keywords: send-hook my_hdr
-----------------------+------------------------------
Changes (by kevin8t8):

* status: new => closed
* resolution: => invalid


Comment:

Just to clarify my previous comment before I close this ticket. The send-
hook's purpose is to change settings based on the recipients of a message,
not to set such recipients.

If you need suggestions on how to make your desired changes, I would
advise emailing mutt-users. They are a creative bunch, and perhaps better
informed than whence you were told to report this as a bug.

One quick suggestion would be to try making the changes in a macro
instead:
{{{
# Override 'm' to set a Cc header
macro index,pager m "<enter-command>my_hdr Cc: Contact Example
<***@example.com><enter><mail>"
# Clean up the cc header so it doesn't appear for replies
send-hook . unmy_hdr cc
}}}

You could override 'm' as the above does, or use another key sequence just
for those cases you want the cc. Again, mutt-users may have better ideas.

--
Ticket URL: <https://dev.mutt.org/trac/ticket/3986#comment:2>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

[Mutt]

#3986: send-hook for Cc and Bcc executed too late
-----------------------+------------------------------
Reporter: alahouze | Owner: mutt-dev
Type: defect | Status: closed
Priority: major | Milestone:
Component: mutt | Version:
Resolution: invalid | Keywords: send-hook my_hdr
-----------------------+------------------------------

Comment (by alahouze):

Actually, the macro must be on "compose", and I added a `send-hook '!~Q'
"push m"` too, which initializes the headers like I want when I create a
new mail.

--
Ticket URL: <https://dev.mutt.org/trac/ticket/3986#comment:3>
Mutt <http://www.mutt.org/>
The Mutt mail user agent