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

[David Bremner]

Jani Nikula <jani at nikula.org> 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