Re: Feedback on ticket 146 - $reverse_realname behavior
On Mon, 10 Jun 2019 at 13:27:08 +0200, Eike Rathke wrote: > On Saturday, 2019-06-08 14:20:49 -0700, Kevin J. McCarthy wrote: > >> Right now, if a To address is missing the personal (name) part, the From >> will be filled in with $realname in the reply. >> >> The ticket submitter expects that if the To address was missing a name, the >> reply From address should be the exact same: missing a name too. >> >> I think it's a reasonable expectation, but would like to confirm that >> opinion with others before I merge the patch. > > Problem is that both can be expected behaviour. > 1) the sender didn't know or fill in the real name, but I would like an >answer to have it; likely in everyday communication > 2) the mail was sent to an address that on purpose doesn't have a name >assigned, like a role account, it may even be it's read and answered >by different persons The ticket assumes that both $reverse_name and $reverse_realname are set. In this configuration mutt should reuse the To: header of the message replied to as-is in the reply’s From: header, even if the name is empty. This is what the names of the configuration variables and their documentation imply ([1][2]) and what I personally expect. Using $realname unconditionally when $reverse_name is set is possible by unsetting $reverse_realname. This works correctly in my experience, however, is not what the ticket is about. [1] http://mutt.org/doc/manual/#reverse-name [2] http://mutt.org/doc/manual/#reverse-realname
Re: Feedback on ticket 146 - $reverse_realname behavior
On Tue, Jun 11, 2019 at 12:26:47PM +0200, rear1019 wrote:
The ticket assumes that both $reverse_name and $reverse_realname are
set. In this configuration mutt should reuse the To: header of the
message replied to as-is in the reply’s From: header, even if the name
is empty.
The documentation certainly says "as-is", so from that side I support
you.
However there are two other factors here, intention of the patch and
precedence.
The initial commit 8bdc339d was implemented as a modification of
existing behavior: the ability to strip out the personal ("realname")
field when $reverse_name is set. The commit message is short, but I
imagine the idea was to *not* accept the realname field, but still have
the ability to reply using the address sent to. The inverse is not the
same thing as *always* using the realname field even if missing.
A further issue is the age of the option and behavior: the commit was
made in March 2000.
If I adjust the documentation, I doubt there will be any complaints.
But if I adjust the behavior, it is almost certain some users will
notice and complain vociferously. So, after more thought, I am leaning
toward adjusting the documentation.
Obtaining the behavior you desire can be accomplished by unsetting
$realname and instead putting the name inside the various $from / my_hdr
settings you use.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: Feedback on ticket 146 - $reverse_realname behavior
On Tue, Jun 11, 2019 at 09:12:06AM -0700, Kevin J. McCarthy wrote: > On Tue, Jun 11, 2019 at 12:26:47PM +0200, rear1019 wrote: > >The ticket assumes that both $reverse_name and $reverse_realname > >are set. In this configuration mutt should reuse the To: header of > >the message replied to as-is in the reply’s From: header, even if > >the name is empty. > > The documentation certainly says "as-is", so from that side I > support you. But that's not *all* it says... in full, it says this: This variable fine-tunes the behavior of the $reverse_name feature. When it is set, mutt will use the address from incoming messages as-is, possibly including eventual real names. When it is unset, mutt will override any such real names with the setting of the $realname variable. I think the key word is *possibly*. So, one has to consider, if it might not always do this, when would it not? I think the most obvious answer to that is, when there is no real name portion present in the address. And this seems to match how it behaves in practice, does it not? > However there are two other factors here, intention of the patch and > precedence. Right. [...] > If I adjust the documentation, I doubt there will be any complaints. > But if I adjust the behavior, it is almost certain some users will > notice and complain vociferously. So, after more thought, I am > leaning toward adjusting the documentation. Right. I use this feature rarely, but I do use it (i.e. in certain folders). I don't expect that people would send me messages with no real name portion, but if anyone did, I would absolutely want the appropriate real name added to my address when I reply. So I consider this an extreme edge case, but the behavior I'd prefer is the current one. > Obtaining the behavior you desire can be accomplished by unsetting > $realname and instead putting the name inside the various $from / > my_hdr settings you use. Indeed. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpUWauANhbGd.pgp Description: PGP signature
