From e31324b7cb80c202858ea1bb0e9bfcaeb6ebb429 Mon Sep 17 00:00:00 2001 From: David Bremner Date: Fri, 19 Aug 2016 07:52:58 +2100 Subject: [PATCH] Re: [PATCH 0/4] Allow specifying alternate names for addresses in other_email --- 40/cafcd95b9df733c2a5d9737380c3ad5ac15d34 | 102 ++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 40/cafcd95b9df733c2a5d9737380c3ad5ac15d34 diff --git a/40/cafcd95b9df733c2a5d9737380c3ad5ac15d34 b/40/cafcd95b9df733c2a5d9737380c3ad5ac15d34 new file mode 100644 index 000000000..7529e884f --- /dev/null +++ b/40/cafcd95b9df733c2a5d9737380c3ad5ac15d34 @@ -0,0 +1,102 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id 3AE836DE0A73 + for ; 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 ; + 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 ; Thu, 18 Aug 2016 03:53:05 -0700 (PDT) +Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2) + (envelope-from ) + 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 +To: Jani Nikula , Shea Levy , + 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." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Thu, 18 Aug 2016 10:53:06 -0000 + +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 + + + -- 2.26.2