Return-Path: <dme@dme.org>
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 <notmuch@notmuchmail.org>; 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 <notmuch@notmuchmail.org>;
	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 <notmuch@notmuchmail.org>; Mon,  8 Sep 2014 02:20:45 -0700
 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id m15so1147721wgh.19
	for <notmuch@notmuchmail.org>; 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 <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 08 Sep 2014 02:20:43 -0700 (PDT)
To: Michal Sojka <sojkam1@fel.cvut.cz>, 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>
	<m2lhpuzlbv.fsf@fenchurch.hh.sledj.net>
	<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 <dme@dme.org>
Date: Mon, 08 Sep 2014 10:20:42 +0100
Message-ID: <m2d2b6zcwl.fsf@fenchurch.hh.sledj.net>
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."
	<notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=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.