From a94a911ae3282015e0d5bd363a07210610f050e7 Mon Sep 17 00:00:00 2001 From: David Edmondson Date: Mon, 8 Sep 2014 10:20:42 +0100 Subject: [PATCH] Re: [PATCH v3] Emacs: Add address completion mechanism implemented in elisp --- 8b/567505431f6f548cd1482a925dd1f721f63362 | 139 ++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 8b/567505431f6f548cd1482a925dd1f721f63362 diff --git a/8b/567505431f6f548cd1482a925dd1f721f63362 b/8b/567505431f6f548cd1482a925dd1f721f63362 new file mode 100644 index 000000000..be8383ad6 --- /dev/null +++ b/8b/567505431f6f548cd1482a925dd1f721f63362 @@ -0,0 +1,139 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 91E61431FBC + for ; Mon, 8 Sep 2014 02:20:51 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 7Z1X5s1GZHGc for ; + Mon, 8 Sep 2014 02:20:45 -0700 (PDT) +Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com + [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client + certificate requested) by olra.theworths.org (Postfix) with ESMTPS id + 35909431FB6 for ; Mon, 8 Sep 2014 02:20:45 -0700 + (PDT) +Received: by mail-wg0-f48.google.com with SMTP id m15so1147721wgh.19 + for ; Mon, 08 Sep 2014 02:20:44 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:to:cc:subject:in-reply-to:references:user-agent + :from:date:message-id:mime-version:content-type; + bh=Wfjrz5Nfn+DSZ84vKZ74XCClyqofnk1/Wg6rXtebopw=; + b=O0Jl1OuQQbahDWVoScXn2X06YdQRkMIwNj1c96GrsjqoHvDIcfG6iUqgeOrICP5deo + PqIt8fiZ75A1CUEVZ+Sj90PboQFbwsIJqHT84XGdx9eWx1fjB1zWRwI35+1twuCuGOU8 + HCxOJ8RiLK8QKWcvZXUG7w10arpJVU4lUF4mAUgr5mtntN0e8ergaLTlDlCSBoPtNjGc + 76KAIwJe3s5quEMX/PTMCMXhyW6LvEn0Ay9NyY9RU8HAh1SQzvThBIprtWANotg/I4uj + R3UbLzUz/hI5nTqJKS+1XwZvO7+Ppwhm7BqEEHu/wwukaYPDbUH3z1hDT2h577/hUnBU + yvvQ== +X-Gm-Message-State: + ALoCoQlxQmXSnaWMu9paNqHabGO6Y4L5Oj9rUXMSmTv0b/9KBXeWFyObpqZqJyVq4ALoMNmWXggy +X-Received: by 10.180.92.134 with SMTP id cm6mr21431435wib.72.1410168043878; + Mon, 08 Sep 2014 02:20:43 -0700 (PDT) +Received: from localhost (disaster-area.hh.sledj.net. [81.149.164.25]) + by mx.google.com with ESMTPSA id u8sm11008506wia.24.2014.09.08.02.20.43 + for + (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Mon, 08 Sep 2014 02:20:43 -0700 (PDT) +To: Michal Sojka , notmuch@notmuchmail.org +Subject: Re: [PATCH v3] Emacs: Add address completion mechanism implemented + in elisp +In-Reply-To: <871trmmqh8.fsf@steelpick.2x.cz> +References: <1407771091-12651-1-git-send-email-sojkam1@fel.cvut.cz> + + <871trmmqh8.fsf@steelpick.2x.cz> +User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-apple-darwin) +From: David Edmondson +Date: Mon, 08 Sep 2014 10:20:42 +0100 +Message-ID: +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +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: Mon, 08 Sep 2014 09:20:51 -0000 + +On Mon, Sep 08 2014, Michal Sojka wrote: +> On Mon, Sep 08 2014, David Edmondson wrote: +>> On Mon, Aug 11 2014, Michal Sojka wrote: +>>> Currently, notmuch has an address completion mechanism that requires +>>> external command to provide completion candidates. This patch adds a +>>> completion mechanism inspired by https://github.com/tjim/nevermore, +>>> which is implemented in Emacs lisp only. +>>> +>>> The core of the new mechanism is the function notmuch-address-harvest +>>> that collects the completion candidates from the notmuch database and +>>> stores them in notmuch-address-completions variable. +>>> notmuch-address-harvest is called on the first entry to message-mode +>>> and runs asychnornously so that the user doesn't have to wait for it +>>> to complete while composing the message. The +>>> notmuch-address-completions variable is used in message-mode as a +>>> source of completion candidates. Currently, there are two ways how the +>>> notmuch-address-completions variable is used. +>>> +>>> First, preexisting address completion mechanism is extended to use +>>> notmuch-address-completions in addition to the external command. This +>>> new behavior is configured by setting notmuch-address-command to nil, +>>> which is the new default. Note that this may *BREAK EXISTING SETUPS* +>>> when the user used external command named "notmuch-addresses", i.e. +>>> the previous default. The result will be that the user will use the +>>> new mechanism instead of the his command. I believe that many users +>>> may not even recognize this because the new mechanism works the same +>>> as http://commonmeasure.org/~jkr/git/notmuch_addresses.git and perhaps +>>> also as other commands suggested at +>>> http://notmuchmail.org/emacstips/#address_completion. +>>> +>>> Second way of using notmuch-address-completions is notmuch-company.el. +>>> This presents the possible completions in a nice popup box after a +>>> short typing delay but requires company-mode to be installed. +>> +>> This looks great, thanks for doing it. It seems like a better approach +>> than id:1409921969-65129-1-git-send-email-dme@dme.org. Some comments: +>> +>> - Adding the address collection to `message-mode-hook' means that it +>> runs every time I start to compose a message. If the address +>> collection is disk intensive, this might be bad for battery life. +> +> The actual harvesting starts only when notmuch-address-completions is +> nil, i.e. when the message-mode is entered for the first time. + +Ah, sorry. I didn't read closely enough. + +>> The set of potential recipients doesn't change _that_ much over time +>> for a typical person, I'd wager. Maybe the hook should only run once a +>> day? (Tunable, of course.) +> +> The current version of the patch has a drawback that harvesting is never +> run again. Adding a tunable option for reharvesting might be a good +> idea. +> +> Since initial harvesting is very slow on non-SSD disk, I want to change +> the implementation so that initially, only addresses matching the +> entered prefix will be harvested, which should be reasonably fast. Then +> full harvest will run on background and once it is finished, +> prefix-based harvesting won't be used anymore. +> +> Maybe prefix-based harvesting could be then used as a fallback when no +> candidates are found in the data from full harvest. This could also be a +> solution to the "reharvest" problem. +> +> I've just returned from vacations so I plan to work on that this week. +> Jani's --output=address patch also looks like something to play with. + +Sounds great, thanks. -- 2.26.2