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

[David Edmondson <dme@dme.org>]

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.