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
course.
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()?
--tobias
