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 at 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.