From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id AE99A6DE610B for ; Sun, 14 Aug 2016 07:26:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=0.141, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 csHk9eXfkuVU for ; Sun, 14 Aug 2016 07:25:59 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by arlo.cworth.org (Postfix) with ESMTPS id 843226DE76FF for ; Sun, 14 Aug 2016 06:36:49 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id q128so51554107wma.1 for ; Sun, 14 Aug 2016 06:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nikula-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Ru8pXx1QDo5bSGsapD4PDhjrN0I90TIG5O3qgHucg/Y=; b=HHoK4DIXh/nyFxN2lV0icTilX2Hxps1QOtw7/LilpGRA3ifrLPcWhefgjSSc/MHUye m+jODUXtY9fXP6RsagR8WuZtoZj6GOtzKHGuilNgQg2G0BNwPBy3svPxVvZ8WPMUbY9k HT1AP/Y2P9PyTY6S+pEYM1Rcup2E2oyCOwFYLedx1whqM8iJS39rbZPT2WCljHHjFwES O3X0M1LyAyN73VvrbryDlNh5QwvUBNkIvOopeV1vEFs+Fo2BaX21u28QlZPUupo11zf4 991SdrlziJtwL7kzCff9yQj1mKlURaPlpgJaaOOMSUlZEjVQ/sYEBmtT+bGWfBAMGSG/ eraw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Ru8pXx1QDo5bSGsapD4PDhjrN0I90TIG5O3qgHucg/Y=; b=IYwiMeUvYP4cuu+Fhd7LmMGVR+r0lWU8/R5cmQZHIrKvk5fapQyq/XSR9mhXOTTSKU mu195JEk1c9kD9953gKVerlah7yPOM9Sx5bQ2dgwvX4fggTmz3sJMHd9kA87WOKKnLBX 6Lm/ooDjlSrw+tiSd3UDuZNmYBFa0B+PEndBbUPwE96hLaGJ3NvHMm6PUkNrworA9oAf wEipfVM+ufz3J8mUTEAucqeqRp1MeyJZod1na7GrebaIEhNK/C19LXxmj6WTHXGfMe0g CeW20E/0lLVKzdXKtgkPEJ1QSLLHjj3VBiXEBv8XnlO2fAH/gPl7uHpTcjgTDfmgNOUF flaw== X-Gm-Message-State: AEkoousWDEHqZYwUPsBY1XWEKgIvnHvUoRLELIPOoZTalULEldSSvUDh/7/PBdZiwQ1r0A== X-Received: by 10.194.29.2 with SMTP id f2mr24579056wjh.161.1471181799706; Sun, 14 Aug 2016 06:36:39 -0700 (PDT) Received: from localhost (mobile-access-bcee63-250.dhcp.inet.fi. [188.238.99.250]) by smtp.gmail.com with ESMTPSA id pm1sm16692784wjb.40.2016.08.14.06.36.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Aug 2016 06:36:39 -0700 (PDT) From: Jani Nikula To: Shea Levy , notmuch@notmuchmail.org Subject: Re: [PATCH 0/4] Allow specifying alternate names for addresses in other_email In-Reply-To: <87oa4vtta4.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> 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> Date: Sun, 14 Aug 2016 16:35:13 +0300 Message-ID: <874m6no4mm.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.20 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: Sun, 14 Aug 2016 14:26:09 -0000 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.jani@nikula.org [2] https://developer.gnome.org/gmime/stable/InternetAddressList.html