From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 3bubFfL8bF8SdwAA0tVLHw (envelope-from ) for ; Thu, 24 Sep 2020 20:09:22 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id YH8UEfL8bF/GRAAA1q6Kng (envelope-from ) for ; Thu, 24 Sep 2020 20:09:22 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [IPv6:2607:5300:201:3100::1657]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id EC2E19406A2 for ; Thu, 24 Sep 2020 20:09:20 +0000 (UTC) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id A16D829C50; Thu, 24 Sep 2020 16:09:12 -0400 (EDT) X-Greylist: delayed 100118 seconds by postgrey-1.36 at nmbug; Thu, 24 Sep 2020 16:09:10 EDT Received: from mail.finestructure.net (mail.finestructure.net [IPv6:2600:3c03::f03c:91ff:fe3b:84bc]) by mail.notmuchmail.org (Postfix) with ESMTPS id 278052931D for ; Thu, 24 Sep 2020 16:09:10 -0400 (EDT) Received: from servo.finestructure.net (unknown [108.58.6.98]) by mail.finestructure.net (Postfix) with ESMTPSA id 4DA2B1F4E3; Thu, 24 Sep 2020 20:09:07 +0000 (UTC) Received: by servo.finestructure.net (Postfix, from userid 1000) id D331816F; Thu, 24 Sep 2020 13:09:05 -0700 (PDT) From: Jameson Graef Rollins To: David Bremner , George Kadianakis , notmuch@notmuchmail.org Subject: Re: emacs: How to tab-complete destination email addresses? In-Reply-To: <87y2kz3w3h.fsf@tethera.net> References: <87h7roa3fe.fsf@riseup.net> <87blhw5usy.fsf@caltech.edu> <87pn6b85u4.fsf@riseup.net> <87y2kz3w3h.fsf@tethera.net> User-Agent: Notmuch/0.31 (https://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Thu, 24 Sep 2020 13:09:05 -0700 Message-ID: <87pn6b3pjy.fsf@caltech.edu> MIME-Version: 1.0 Message-ID-Hash: 6KFECVRK644B22W2G6DAEMYOH36DKTWC X-Message-ID-Hash: 6KFECVRK644B22W2G6DAEMYOH36DKTWC X-MailFrom: jrollins@finestructure.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2607:5300:201:3100::1657 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Spam-Score: 0.03 X-TUID: KU+ZK/97zt/0 On Thu, Sep 24 2020, David Bremner wrote: > George Kadianakis writes: > >> So I guess this ordering should happen internally in notmuch-address, >> right? Perhaps as a new type of "--sort" option like "--most-frequent" >> or "--best-fit". >> >> If this is the right way to do it, perhaps I'll take a stab at it over >> the next days. If it's not the right way to do it, please let me know so >> that I don't do useless things! :) > > there was some discussion about upstreaming some of the features of > notmuch-addrlookup-c into notmuch-address [1]. I'm not sure what > happened there, but maybe this helps. I wasn't aware of notmuch-addrlookup-c as a separate tool, but I just tried it and it looks like it could be promising. If it has better address sorting that definitely seems like something that would be good to pull in upstream. >> Hmm, I've never used this interface but if you are talking about the >> "--output" switch I see that they can be combined. So like you can do: >> >> $ notmuch address --output sender --output recipients jameson >> >> to combine both To: and From:. > > Maybe the elisp 'internal' front-end needs to be updated to (optionally) do what > Jamie asks. So I don't think these are the right options to consider, but I'm not sure. If I'm searching for addresses associated with the user "jameson", I think I *don't* want --output=recipients, since I imagine that includes all the addresses that "jameson" has sent messages *to*, which is definitely not what I would want included. But maybe I'm not understanding. It seems like emacs must be creating a more nuanced set of arguments somehow... jamie.