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 mDCDIg14a19/GQAA0tVLHw (envelope-from ) for ; Wed, 23 Sep 2020 16:30:05 +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 mE6WHg14a18KDgAA1q6Kng (envelope-from ) for ; Wed, 23 Sep 2020 16:30:05 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (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 27F7C94077C for ; Wed, 23 Sep 2020 16:30:04 +0000 (UTC) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 4531829BDA; Wed, 23 Sep 2020 12:29:57 -0400 (EDT) X-Greylist: delayed 564 seconds by postgrey-1.36 at nmbug; Wed, 23 Sep 2020 12:29:55 EDT Received: from mail.finestructure.net (mail.finestructure.net [45.79.153.190]) by mail.notmuchmail.org (Postfix) with ESMTPS id 862DD20651 for ; Wed, 23 Sep 2020 12:29:55 -0400 (EDT) Received: from servo.finestructure.net (unknown [108.58.6.98]) by mail.finestructure.net (Postfix) with ESMTPSA id 1BDDA1F4E3; Wed, 23 Sep 2020 16:20:31 +0000 (UTC) Received: by servo.finestructure.net (Postfix, from userid 1000) id AD19816E; Wed, 23 Sep 2020 09:20:29 -0700 (PDT) From: Jameson Graef Rollins To: George Kadianakis , notmuch@notmuchmail.org Subject: Re: emacs: How to tab-complete destination email addresses? In-Reply-To: <87h7roa3fe.fsf@riseup.net> References: <87h7roa3fe.fsf@riseup.net> User-Agent: Notmuch/0.31 (https://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Wed, 23 Sep 2020 09:20:29 -0700 Message-ID: <87blhw5usy.fsf@caltech.edu> MIME-Version: 1.0 Message-ID-Hash: VM37F66E7PQTS7X2LKBA7R5PMISUW4A3 X-Message-ID-Hash: VM37F66E7PQTS7X2LKBA7R5PMISUW4A3 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 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Spam-Score: 0.03 X-TUID: O46SeEMtR4YM On Wed, Sep 23 2020, George Kadianakis wrote: > One way forward is to switch from using notmuch-address to using > something like bbdb and manually curate my database (since bbdb offers > this capability). > > But I think the right way would be to somehow introduce a bunch of > heuristics in notmuch/emacs so that the right email address is chosen > for each person. For example, if I tab-complete "Alice", I would like > notmuch to give me the email address that Alice has used herself most > frequently the past few times she contacted me. > > Perhaps there is something that does what I want already? > If that's the case, I'd love to be pointed to a good solution! I find the convenience of not having to maintain an address book to be a huge win with the use of notmuch-address, so I'm generally fine to filter through the offered addresses to find the one that I generally recognize to be the most viable. That said, an obvious improvement (as you suggest) would be to order addresses based on most recent+frequent use, so that the most recently used one shows up first. The problem I have, though, is that for some reason that I don't understand the interface can use To: address, or From: addresses, but not both. This is by far the most annoying thing to me, since in both scenarios there will end up being missing addresses that I need that I then have to go search for manually. If the interface could be configured to return most From: and To: address that would be a big improvement imho. jamie.