-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Friday, August 7 at 01:52 AM, quoth Erik Christiansen:
>> Right. Here's the reasoning: the message needs to be built *before*
>> the send-hook triggers. For example, what would you expect the
>> following to do?
>>
>> send-hook '~h Reply-to:' 'my_hdr Reply-to: m...@here.com'
>>
>> When should the Reply-to header be constructed?
>
> When $edit_headers is set, it can only be fully effectively constructed
> on exit from the editor.
It's true that the headers can change when the user is editing the
message, and so there's a good argument for only triggering send-hooks
AFTER the $editor exits. BUT, how annoying would it be to add all the
relevant headers every time? Okay, if you know how to script your
editor, not annoying at all, but still, mutt provides From, To, CC,
Bcc, Subject, and Reply-To headers when you start your $editor. It's
gotta get those from *somewhere*.
Consider if you were instead changing the Subject header. For example:
send-hook '~C d...@example.com' 'my_hdr Subject: [dudemail]'
Ostensibly, the idea behind that hook is to provide a template
subject-line for all mail sent to d...@example.com; but if send-hooks
are only triggered AFTER the message is composed, that's basically
useless. At the same time, what if you add "dude" to the recipients
WHILE you edit the email - if the hook is only triggered BEFORE the
message is composed, that's basically useless too!
Essentially, any choice the mutt developers make here is going to
annoy *somebody* who thinks the hook should work slightly differently.
Anyway, send-hooks aren't really good at editing headers anyway. I
find them much more useful for doing things like changing PGP
encryption settings, modifying the $editor string based on the
recipient so that I can change my vim settings (e.g. if I'm sending to
certain mailing lists, I don't want to use UTF-8, but otherwise, I
do), changing the value of $record based on the recipient, that sort
of thing.
> That is precisely what I am attempting. Edited headers can only be
> seen by mutt on exit from the editor, so that's when it is able to
> process them. From this side of the briar patch, that seems pretty
> straightforward.
And what if I want to change my $editor string based on the recipients
of the message?
> OK, despite being a "compose-hook", send-hook does not "have any
> effect on the current message" in this context. I'll have to find
> another way to suppress the list-specific "Reply-to:" header when
> composing a new email.
Three thoughts:
1. lots of people use folder-hooks to set headers like that.
Personally, I dislike this idea, because I want mutt to
recognize list messages no matter where they happen to be
stored (otherwise, what's the point of the ~l matcher?). But
you could use it for this Reply-To purpose.
2. You could also use a message-hook, that triggers when you
display the message, like this:
message-hook '~C list' 'my_hdr Reply-to: foo'
That is a little hack-like too, because it doesn't work from
the index, but combine this with a folder hook (for the index),
and you may be in business.
3. You could use an $editor trick, like this (assuming you use
vim):
send-hook '~C list' 'set editor="vim '+%s/^Reply-To:/& foo/i'"
~Kyle
- --
A government which robs Peter to pay Paul can always depend on the
support of Paul.
-- George Bernard Shaw
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKex1sAAoJECuveozR/AWe9qQP/RhCkzcR5aSlv+CtgdeURifr
8VSsefSggsLMjUEwiuG4plvDzikpua9A3c+RAmyuiVNZvE7vgBA9HdZMASBudFNl
NGFUI+FQjiOYcJrkkx3BVTpN6ouYM7i4WnECYWtYtXqkX5HO/gQYr7Y+BS0fYHZn
K8Icwetmf7BTn5wtHWgFQ24D0R/D2i1jpD2RXdoZPFD8GvkYPHSIcLqOsIQyQGbX
2rWGGLaU67SOeTErt85ry328N8r1L0Kpq0HSuSQPVNB++IP2gU1Bbt0LmDtN3/zb
AjHUByylAgfqUgRin8UXuFN+wahN5G4C1e57G9sGvFDfQs2UKrpOYvC07yp4gdMB
z8fARb33lfoNumF5E/QFZWmeAWABJTmZOF9f6tzUIHlBN5EYy6XkdZ4iFk6Zry6i
+krvwsNrBgfdBCCuAic/K37BXHoXdV8lHDOj+zV1xi00r445MeISs5VvVIu06+bc
2aR3sDgY9NzX8h6L3l5hVNMRDnqBHsLa1tq4enYeZoR7xWsxViGoRrJWSIZXl3xD
yUNFFr8jmtYLJeJ55n4vKdcdJp8xfrIYkosasGOdVP1zcjJFXe1xvUTjVlsLB18u
IC2LSuyHyhm04uzqRN59fEtQnIJGqJXo0jMoDhp0sK/QORlONee1HjLBQC5PN+qv
dTnBTkBG6XW1tnnLYByo
=8wWS
-----END PGP SIGNATURE-----
