[PATCH] reverse_name: optionally read {,X-}Envelope-To:

Tobias Girstmair t-mutt at girst.at
Fri May 17 08:40:05 UTC 2019

Hi, thanks for your feedback -- very much appreciated.
(this email was supposed to go out at the same time as the v2 patch, but 
it got rejected because I had my mailalias wrong. how appropriate. I'm 
also replying to your later mail at the end)

On Thu, May 16, 2019 at 04:45:49PM -0700, Kevin J. McCarthy wrote:
>Thanks for sending the patch.  Right now we're in the middle of the 
>freeze for 1.12.0, so no commits of this sort are happening.  However, 
>I do have some feedback.

I figured, but was a bit impatient. I'll rebase after the release, of 

>It looks like you left out the part of the patch that is setting 
>env->envelope_to.  Also, a new envelope field would need to be saved 
>and restored in hcache.c.  

I apologize, what a stupid failure on my end. I developed against the 
tarball and only afterwards applied the patches to master. In my 
impatience I forgot to make sure all patches applied correctly (which 
they obviously didn't).
hcache was not on my radar and is implemented for the v2.

>This might invite further discussion of patterns such as ~t, ~C, etc.

I'm not really sure what you mean here. reverse_name is already looking 
at To: and CC:. Patterns aren't involved in this feature at all.

>If something like this were to go in, I think it should be bundled 
>with the $reverse_name functionality, not as a new option.

That would be my preference too (making it optional was just to not 
change default behaviour).

>All that said, my impression is that this is too specific.  The header 
>you are referencing is non-standard, and varies based on the MTA. 

The header is non-standard, but widely available. It also fixes an 
annoyance for some users, while not breaking anything for everyone else.

>Others gave suggestions in the threads you mentioned for various 
>workarounds.  I'm -1 on this, but I'll give it some more thought.

Those workarounds take manual configuration for all lists, involve 
piping messages to external programs or aren't really flexible (more 
than one from address). On the other hand, there's this option that 
looks like it does exactly what you'd want, but doesn't.

On Thu, May 16, 2019 at 08:11:28PM -0700, Kevin J. McCarthy wrote:
>I'm still not leaning towards accepting :-) , but since you're getting 

Even if it won't end up merged, I'd rather have a complete patch 
documented somewhere, and not just broken ones.

>the patch fixed up, you should also add a line to mutt_free_envelope(). 

what about in mutt_merge_envelopes()?


More information about the Mutt-dev mailing list