From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <david@tethera.net>
Received: from localhost (localhost [127.0.0.1])
 by arlo.cworth.org (Postfix) with ESMTP id 3AE836DE0A73
 for <notmuch@notmuchmail.org>; Thu, 18 Aug 2016 03:53:06 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at cworth.org
X-Spam-Flag: NO
X-Spam-Score: -0.007
X-Spam-Level: 
X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[AWL=0.004, 
 SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled
Received: from arlo.cworth.org ([127.0.0.1])
 by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id KojutkY6O4rY for <notmuch@notmuchmail.org>;
 Thu, 18 Aug 2016 03:53:05 -0700 (PDT)
Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])
 by arlo.cworth.org (Postfix) with ESMTPS id 638AD6DE0A6F
 for <notmuch@notmuchmail.org>; Thu, 18 Aug 2016 03:53:05 -0700 (PDT)
Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2)
 (envelope-from <david@tethera.net>)
 id 1baKwi-0007F4-VY; Thu, 18 Aug 2016 06:53:12 -0400
Received: (nullmailer pid 7350 invoked by uid 1000);
 Thu, 18 Aug 2016 10:52:58 -0000
From: David Bremner <david@tethera.net>
To: Jani Nikula <jani@nikula.org>, Shea Levy <shea@shealevy.com>,
 notmuch@notmuchmail.org
Subject: Re: [PATCH 0/4] Allow specifying alternate names for addresses in
 other_email
In-Reply-To: <874m6no4mm.fsf@nikula.org>
References: <1470776118-5070-1-git-send-email-shea@shealevy.com>
 <87k2fk98yh.fsf@nikula.org>
 <87oa4vtta4.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me>
 <874m6no4mm.fsf@nikula.org>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Thu, 18 Aug 2016 07:52:58 -0300
Message-ID: <87oa4qqrg5.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: notmuch@notmuchmail.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Use and development of the notmuch mail system."
 <notmuch.notmuchmail.org>
List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,
 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch/>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,
 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 10:53:06 -0000

Jani Nikula <jani@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