[PATCH 0/4] Allow specifying alternate names for addresses in other_email

[Jani Nikula]

On Sun, 14 Aug 2016, Shea Levy <shea at shealevy.com> wrote:
> Jani Nikula <jani at nikula.org> writes:
>
>> On Tue, 09 Aug 2016, Shea Levy <shea at shealevy.com> wrote:
>>> Currently, while notmuch-reply will recognize email addresses other than
>>> the main address with user.other_email, it always sets the name part of
>>> the address in the envelope-from and From headers to user.name. This
>>> patchset enables specifying names on a per-address basis with a new
>>> user.other_name property. Presumably other users of user.other_email
>>> may want to use this as well, but those are not updated currently.
>>
>> I am not convinved by adding another configuration option, especially
>> when it has to be in sync with another configuration option (ordering in
>> user.other_name having to match user.other_email). I would much prefer
>> allowing (but not requiring) "Name <user at example.org>" style addresses
>> both in user.primary_email and user.other_email.
>>
>
> This would be fine with me. Is there already code in place to separate
> out the name and email values from that kind of email address?

I think we should use gmime for this, and expect the configuration to be
a comma separated list of addresses, specifically in the format that
internet_address_list_parse_string() parses [2]. On the plus side, it'll
handle most of the weird corner cases about (lists of) email addresses,
and we can probably safely ignore the ones it doesn't handle. We already
use that stuff in notmuch-show.c and notmuch-reply.c. On the minus side,
using the functions is about as much fun as string manipulation
generally is in C.

Then there's the annoying detail that this'll change the format of the
config from a semicolon separated list to a comma separated list. This
means switching from using g_key_file_get_string_list() to
g_key_file_get_string(). But we also need to have backward compatibility
somehow. One option is to add a new config option (didn't I just frown
on adding new ones?) that would replace all of user.name,
user.primary_email, and user.other_email, making the first in the list
the primary one. So we could check if, say, user.email is present, and
use that for all of the name/primary/other configuration, falling back
to the separate fields otherwise. This is also a safe option in case
some other software uses the configuration options directly.

Anyway, this will be slightly tedious to code, and some of the changes
might be a bit controversial, so I suggest waiting until we get feedback
from others first. (David, I'm looking at you!)

>> With a cursory glance at the implementation, I wonder if you could just
>> pick the name based on the address you've picked earlier, and leave the
>> address matching mostly as it is. Would save some passing of parameters
>> around. Maybe.
>>
>
> Hmm, I'm not sure what you mean by this, sorry. Can you expand?

Only match the *address* part, and when you've found a match, find the
corresponding name part. Or do you need to be able to distinguish
between different names with the same address?

No matter what, I think the first thing should be changing just the
config, and then building the rest on top afterwards.

>> Additionally, I'd very much like to have my series [1] merged
>> first. It'll be *much* easier to rebase your series on top than the
>> other way around...
>>
>
> Happy to rebase my work on yours.

Of course, lacking review, there's no guarantee my series actually gets
merged. It's open source, first come, first served!


BR,
Jani.


>>
>> [1] id:cover.1471088022.git.jani at nikula.org

[2] https://developer.gnome.org/gmime/stable/InternetAddressList.html