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

[David Bremner]

Jani Nikula  writes:

> 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.

I guess if you wanted to be very friendly, you could support "virtual
keys" for notmuch config so that "notmuch config get user.email" still
works. Maybe that's already what you intend to suggest there. We already
have config keys that are not stored in .notmuch-config

I do agree that have two parallel arrays that the user is supposed to
keep in sync is a classic bad interface design (we basically introduce
structs/OOP by saying that's bad ;)). Other than that I'm open to what
the config options look like, since setting them up is a rare operation.

I think the only places in notmuch these config options are used is in
notmuch-reply, and in the emacs client.

It occurs to me that another option is some kind of versioning of config
files, and yet another upgrade process (since we rewrite the whole
config file anyway). This might be even more tedious to write, but at
least the logic of dealing with different config file versions would all
be in one place.

> This is also a safe option in case some other software uses the
> configuration options directly.

I guess there's no safe option if people read the file directly, but I
keep telling people not to do that ;). 

> 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!)

not sure if these are the droids^Wfeedbacks you are looking for.

d



___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

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

[Jani Nikula]

On Sun, 14 Aug 2016, Jani Nikula  wrote:
> 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].

Here's a little sample to get started and play around. Build using
something along the lines of:

gcc $(pkg-config --cflags gmime-2.6 --libs gmime-2.6) internetaddress.c

You can try e.g.

$ ./a.out "J. Random Hacker , d...@example.org, \"Hacker, J. 
Random\" "
name[0]: J. Random Hacker
addr[0]: j...@example.org
name[1]: (null)
addr[1]: d...@example.org
name[2]: Hacker, J. Random
addr[2]: hac...@example.com

--->%--

#include 
#include 
#include 

#include 

int main(int argc, char *argv[])
{
InternetAddressList *list;
InternetAddress *mailbox;
int i;

if (argc != 2) {
fprintf(stderr, "usage: %s address-list\n", argv[0]);
return EXIT_FAILURE;
}

list = internet_address_list_parse_string(argv[1]);

for (i = 0; i < internet_address_list_length(list); i++) {
InternetAddress *addr;
InternetAddressMailbox *mbox;

addr = internet_address_list_get_address(list, i);

if (INTERNET_ADDRESS_IS_GROUP(addr)) {
printf("[%d] is a group, ignoring\n", i);
continue;
}

mbox = INTERNET_ADDRESS_MAILBOX(addr);

printf("name[%d]: %s\n", i, internet_address_get_name(addr));
printf("addr[%d]: %s\n", i, 
internet_address_mailbox_get_addr(mbox));
}

return EXIT_SUCCESS;
}
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

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

[Jani Nikula]

On Sun, 14 Aug 2016, Shea Levy  wrote:
> Jani Nikula  writes:
>
>> On Tue, 09 Aug 2016, Shea Levy  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 " 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.j...@nikula.org

[2] https://developer.gnome.org/gmime/stable/InternetAddressList.html
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

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

[Shea Levy]

Hi Jani,

Jani Nikula  writes:

> On Tue, 09 Aug 2016, Shea Levy  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 " 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?

>
> 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?

>
> 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.

>
> BR,
> Jani.
>
>
> [1] id:cover.1471088022.git.j...@nikula.org
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

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

[Jani Nikula]

On Tue, 09 Aug 2016, Shea Levy  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 " style addresses
both in user.primary_email and user.other_email.

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.

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...

BR,
Jani.


[1] id:cover.1471088022.git.j...@nikula.org
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch