Re: [PATCH v3] Emacs: Add address completion mechanism implemented in elisp

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