40/cafcd95b9df733c2a5d9737380c3ad5ac15d34

   1 Return-Path: <david@tethera.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5  by arlo.cworth.org (Postfix) with ESMTP id 3AE836DE0A73\r
   6  for <notmuch@notmuchmail.org>; Thu, 18 Aug 2016 03:53:06 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.007\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[AWL=0.004,\r
  12   SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id KojutkY6O4rY for <notmuch@notmuchmail.org>;\r
  16  Thu, 18 Aug 2016 03:53:05 -0700 (PDT)\r
  17 Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
  18  by arlo.cworth.org (Postfix) with ESMTPS id 638AD6DE0A6F\r
  19  for <notmuch@notmuchmail.org>; Thu, 18 Aug 2016 03:53:05 -0700 (PDT)\r
  20 Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2)\r
  21  (envelope-from <david@tethera.net>)\r
  22  id 1baKwi-0007F4-VY; Thu, 18 Aug 2016 06:53:12 -0400\r
  23 Received: (nullmailer pid 7350 invoked by uid 1000);\r
  24  Thu, 18 Aug 2016 10:52:58 -0000\r
  25 From: David Bremner <david@tethera.net>\r
  26 To: Jani Nikula <jani@nikula.org>, Shea Levy <shea@shealevy.com>,\r
  27  notmuch@notmuchmail.org\r
  28 Subject: Re: [PATCH 0/4] Allow specifying alternate names for addresses in\r
  29  other_email\r
  30 In-Reply-To: <874m6no4mm.fsf@nikula.org>\r
  31 References: <1470776118-5070-1-git-send-email-shea@shealevy.com>\r
  32  <87k2fk98yh.fsf@nikula.org>\r
  33  <87oa4vtta4.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me>\r
  34  <874m6no4mm.fsf@nikula.org>\r
  35 User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1\r
  36  (x86_64-pc-linux-gnu)\r
  37 Date: Thu, 18 Aug 2016 07:52:58 -0300\r
  38 Message-ID: <87oa4qqrg5.fsf@zancas.localnet>\r
  39 MIME-Version: 1.0\r
  40 Content-Type: text/plain\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.22\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45  <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  47  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Thu, 18 Aug 2016 10:53:06 -0000\r
  54 \r
  55 Jani Nikula <jani@nikula.org> writes:\r
  56 \r
  57 > Then there's the annoying detail that this'll change the format of the\r
  58 > config from a semicolon separated list to a comma separated list. This\r
  59 > means switching from using g_key_file_get_string_list() to\r
  60 > g_key_file_get_string(). But we also need to have backward compatibility\r
  61 > somehow. One option is to add a new config option (didn't I just frown\r
  62 > on adding new ones?) that would replace all of user.name,\r
  63 > user.primary_email, and user.other_email, making the first in the list\r
  64 > the primary one. So we could check if, say, user.email is present, and\r
  65 > use that for all of the name/primary/other configuration, falling back\r
  66 > to the separate fields otherwise.\r
  67 \r
  68 I guess if you wanted to be very friendly, you could support "virtual\r
  69 keys" for notmuch config so that "notmuch config get user.email" still\r
  70 works. Maybe that's already what you intend to suggest there. We already\r
  71 have config keys that are not stored in .notmuch-config\r
  72 \r
  73 I do agree that have two parallel arrays that the user is supposed to\r
  74 keep in sync is a classic bad interface design (we basically introduce\r
  75 structs/OOP by saying that's bad ;)). Other than that I'm open to what\r
  76 the config options look like, since setting them up is a rare operation.\r
  77 \r
  78 I think the only places in notmuch these config options are used is in\r
  79 notmuch-reply, and in the emacs client.\r
  80 \r
  81 It occurs to me that another option is some kind of versioning of config\r
  82 files, and yet another upgrade process (since we rewrite the whole\r
  83 config file anyway). This might be even more tedious to write, but at\r
  84 least the logic of dealing with different config file versions would all\r
  85 be in one place.\r
  86 \r
  87 > This is also a safe option in case some other software uses the\r
  88 > configuration options directly.\r
  89 \r
  90 I guess there's no safe option if people read the file directly, but I\r
  91 keep telling people not to do that ;). \r
  92 \r
  93 > Anyway, this will be slightly tedious to code, and some of the changes\r
  94 > might be a bit controversial, so I suggest waiting until we get feedback\r
  95 > from others first. (David, I'm looking at you!)\r
  96 \r
  97 not sure if these are the droids^Wfeedbacks you are looking for.\r
  98 \r
  99 d\r
 100 \r
 101 \r
 102 \r