[Patch v2 1/2] emacs: show: document the mark unread defcustom function
On Sat, Sep 06 2014, Mark Walters wrote: > --- > emacs/notmuch-show.el |8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el > index 7549fbb..5695d95 100644 > --- a/emacs/notmuch-show.el > +++ b/emacs/notmuch-show.el > @@ -224,7 +224,13 @@ For example, if you wanted to remove an \"unread\" tag > and add a >:group 'notmuch-show) > > (defcustom notmuch-show-mark-read-function > #'notmuch-show-seen-current-message > - "Function to control which messages are marked read." > + "Function to control which messages are marked read. > + > +The function should take two arguments START and END which will > +be the start and end of the visible portion of the buffer and > +should mark the appropriate messages read by applying > +`notmuch-show-mark-read'. This function will be called after > +every user interaction with notmuch." This patch LGTM. Now that we know more I would have liked this function would not take the START & END parameters but the function itself could have done (window-start) (window-end) if it so desires... ... as we have discussed in IRC my current version uses (point) in place of END (window-end) and I may drop START too (while investigating Mark's IRC-given suggestions). Anyway, the ship may have sailed and therefore I am inclined to give +1 to this patch... Tomi >:type 'function >:group 'notmuch-show) > > -- > 1.7.10.4 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v3] Emacs: Add address completion mechanism implemented in elisp
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. > 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. Cheers, -Michal > > - The addition of company mode support (which I haven't tried) should be > a separate patch in the series. > >> --- >> Changes from v1: >> - Use of notmuch-parser.el instead of the custom parser in the >> original code. The notmuch parser is slightly faster. >> - Use of functions in notmuch-query.el instead of functions in the >> original code with almost the same functionality. >> - Integrated with existing completion mechanism in notmuch. >> - notmuch-company.el was moved from emacs/contrib to emacs and >> no-byte-compile directive was added to it. >> - Aligned with notmuch naming conventions. >> - Documented bugs found in notmuch-company.el >> >> Changes from v2: >> - Updated Makefile.local to not conflict with current master >> --- >> emacs/Makefile.local | 6 ++- >> emacs/notmuch-address.el | 95 >> +++- >> emacs/notmuch-company.el | 69 +++ >> emacs/notmuch-lib.el | 3 ++ >> 4 files changed, 163 insertions(+), 10 deletions(-) >> create mode 100644 emacs/notmuch-company.el >> >> diff --git a/emacs/Makefile.local b/emacs/Makefile.local >> index 1109cfa..6c93e73 100644 >> --- a/emacs/Makefile.local >> +++ b/emacs/Makefile.local >> @@ -20,6 +20,7 @@ emacs_sources := \ >> $(dir)/notmuch-print.el \ >> $(dir)/notmuch-version.el \ >> $(dir)/notmuch-jump.el \ >> +$(dir)/notmuch-company.el >> >> $(dir)/notmuch-version.el: $(dir)/Makefile.local version.stamp >> $(dir)/notmuch-version.el: $(srcdir)/$(dir)/notmuch-version.el.tmpl >> @@ -30,7 +31,10 @@ $(dir)/notmuch-version.el: >>
[PATCH v3] Emacs: Add address completion mechanism implemented in elisp
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.
[Patch v2 0/2] emacs: show: mark messages read if seen in buffer
I like the general approach. On Sat, Sep 06 2014, Mark Walters wrote: > There are two changes from v1. First patch 1 is new. Secondly I have > modified the defcustom for the second patch. It is slightly fiddly as > my function has a parameter the default function does not. The > defcustom in the previous patch worked but it was unable to parse > itself so when you revisited the defcustom it looked like you had > specified the lisp manually rather than having selected one of the two > options. Is this because you want to include the parameter at the same point in the custom definition? It's not uncommon to have a separate variable for (things like) the proportion. It would make the declaration much simpler. > I like this version of the mark read function; but it is quite a lot > of code (all unused unless the user selects this option so it is low > risk). If people would prefer not to include it then I can just post > the relevant code to the wiki and people can add it to their .emacs > file if they want this function. If it's not the default, then I would be in favour of including it.
[PATCH v3] Emacs: Add address completion mechanism implemented in elisp
On Mon, 08 Sep 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 > 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.) Just a meta comment really: Austin is very close to posting a patch adding a timestamp to messages in the database (I think roughly last modify time). Once that is in an address-harvest query of the form all messages with any changes since the last harvest should be simple and fast. A second more general comment: if something like Jani's patch id:1410021689-15901-1-git-send-email-jani at nikula.org goes in the harvesting from addresses is hugely faster (circa 20 times, see id:8761h0fxow.fsf at qmul.ac.uk ) than harvesting to,cc addresses so some people might want to tweak/customize that. Best wishes Mark > > - The addition of company mode support (which I haven't tried) should be > a separate patch in the series. > >> --- >> Changes from v1: >> - Use of notmuch-parser.el instead of the custom parser in the >> original code. The notmuch parser is slightly faster. >> - Use of functions in notmuch-query.el instead of functions in the >> original code with almost the same functionality. >> - Integrated with existing completion mechanism in notmuch. >> - notmuch-company.el was moved from emacs/contrib to emacs and >> no-byte-compile directive was added to it. >> - Aligned with notmuch naming conventions. >> - Documented bugs found in notmuch-company.el >> >> Changes from v2: >> - Updated Makefile.local to not conflict with current master >> --- >> emacs/Makefile.local | 6 ++- >> emacs/notmuch-address.el | 95 >> +++- >> emacs/notmuch-company.el | 69 +++ >> emacs/notmuch-lib.el | 3 ++ >> 4 files changed, 163 insertions(+), 10 deletions(-) >> create mode 100644 emacs/notmuch-company.el >> >> diff --git a/emacs/Makefile.local b/emacs/Makefile.local >> index 1109cfa..6c93e73 100644 >> --- a/emacs/Makefile.local >> +++ b/emacs/Makefile.local >> @@ -20,6 +20,7 @@ emacs_sources := \ >> $(dir)/notmuch-print.el \ >> $(dir)/notmuch-version.el \ >> $(dir)/notmuch-jump.el \ >> +$(dir)/notmuch-company.el >> >> $(dir)/notmuch-version.el: $(dir)/Makefile.local version.stamp >> $(dir)/notmuch-version.el: $(srcdir)/$(dir)/notmuch-version.el.tmpl >> @@ -30,7 +31,10 @@ $(dir)/notmuch-version.el: >> $(srcdir)/$(dir)/notmuch-version.el.tmpl >> emacs_images := \ >> $(srcdir)/$(dir)/notmuch-logo.png >> >> -emacs_bytecode = $(emacs_sources:.el=.elc) >> +# Do not try to install files that are not byte-compiled. >> +emacs_no_byte_compile := $(dir)/notmuch-company.el >> + >> +emacs_bytecode = $(patsubst
[PATCH v3] Emacs: Add address completion mechanism implemented in elisp
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 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 addition of company mode support (which I haven't tried) should be a separate patch in the series. > --- > Changes from v1: > - Use of notmuch-parser.el instead of the custom parser in the > original code. The notmuch parser is slightly faster. > - Use of functions in notmuch-query.el instead of functions in the > original code with almost the same functionality. > - Integrated with existing completion mechanism in notmuch. > - notmuch-company.el was moved from emacs/contrib to emacs and > no-byte-compile directive was added to it. > - Aligned with notmuch naming conventions. > - Documented bugs found in notmuch-company.el > > Changes from v2: > - Updated Makefile.local to not conflict with current master > --- > emacs/Makefile.local | 6 ++- > emacs/notmuch-address.el | 95 > +++- > emacs/notmuch-company.el | 69 +++ > emacs/notmuch-lib.el | 3 ++ > 4 files changed, 163 insertions(+), 10 deletions(-) > create mode 100644 emacs/notmuch-company.el > > diff --git a/emacs/Makefile.local b/emacs/Makefile.local > index 1109cfa..6c93e73 100644 > --- a/emacs/Makefile.local > +++ b/emacs/Makefile.local > @@ -20,6 +20,7 @@ emacs_sources := \ > $(dir)/notmuch-print.el \ > $(dir)/notmuch-version.el \ > $(dir)/notmuch-jump.el \ > + $(dir)/notmuch-company.el > > $(dir)/notmuch-version.el: $(dir)/Makefile.local version.stamp > $(dir)/notmuch-version.el: $(srcdir)/$(dir)/notmuch-version.el.tmpl > @@ -30,7 +31,10 @@ $(dir)/notmuch-version.el: > $(srcdir)/$(dir)/notmuch-version.el.tmpl > emacs_images := \ > $(srcdir)/$(dir)/notmuch-logo.png > > -emacs_bytecode = $(emacs_sources:.el=.elc) > +# Do not try to install files that are not byte-compiled. > +emacs_no_byte_compile := $(dir)/notmuch-company.el > + > +emacs_bytecode = $(patsubst %.el,%.elc,$(filter-out > $(emacs_no_byte_compile),$(emacs_sources))) > > # Because of defmacro's and defsubst's, we have to account for load > # dependencies between Elisp files when byte compiling. Otherwise, > diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el > index fa65cd5..a50f4f4 100644 > --- a/emacs/notmuch-address.el > +++ b/emacs/notmuch-address.el > @@ -20,14 +20,18 @@ > ;; Authors: David Edmondson > > (require 'message) > +(require 'notmuch-query) > +(require 'notmuch-parser) > > ;; > > -(defcustom notmuch-address-command "notmuch-addresses" > - "The command which generates possible addresses. It must take a > -single argument and output a list of possible matches, one per > -line." > - :type 'string > +(defcustom
Re: [PATCH v3] Emacs: Add address completion mechanism implemented in elisp
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.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 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 addition of company mode support (which I haven't tried) should be a separate patch in the series. --- Changes from v1: - Use of notmuch-parser.el instead of the custom parser in the original code. The notmuch parser is slightly faster. - Use of functions in notmuch-query.el instead of functions in the original code with almost the same functionality. - Integrated with existing completion mechanism in notmuch. - notmuch-company.el was moved from emacs/contrib to emacs and no-byte-compile directive was added to it. - Aligned with notmuch naming conventions. - Documented bugs found in notmuch-company.el Changes from v2: - Updated Makefile.local to not conflict with current master --- emacs/Makefile.local | 6 ++- emacs/notmuch-address.el | 95 +++- emacs/notmuch-company.el | 69 +++ emacs/notmuch-lib.el | 3 ++ 4 files changed, 163 insertions(+), 10 deletions(-) create mode 100644 emacs/notmuch-company.el diff --git a/emacs/Makefile.local b/emacs/Makefile.local index 1109cfa..6c93e73 100644 --- a/emacs/Makefile.local +++ b/emacs/Makefile.local @@ -20,6 +20,7 @@ emacs_sources := \ $(dir)/notmuch-print.el \ $(dir)/notmuch-version.el \ $(dir)/notmuch-jump.el \ + $(dir)/notmuch-company.el $(dir)/notmuch-version.el: $(dir)/Makefile.local version.stamp $(dir)/notmuch-version.el: $(srcdir)/$(dir)/notmuch-version.el.tmpl @@ -30,7 +31,10 @@ $(dir)/notmuch-version.el: $(srcdir)/$(dir)/notmuch-version.el.tmpl emacs_images := \ $(srcdir)/$(dir)/notmuch-logo.png -emacs_bytecode = $(emacs_sources:.el=.elc) +# Do not try to install files that are not byte-compiled. +emacs_no_byte_compile := $(dir)/notmuch-company.el + +emacs_bytecode = $(patsubst %.el,%.elc,$(filter-out $(emacs_no_byte_compile),$(emacs_sources))) # Because of defmacro's and defsubst's, we have to account for load # dependencies between Elisp files when byte compiling. Otherwise, diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index fa65cd5..a50f4f4 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -20,14 +20,18 @@ ;; Authors: David Edmondson d...@dme.org (require 'message) +(require 'notmuch-query) +(require 'notmuch-parser) ;; -(defcustom notmuch-address-command notmuch-addresses - The command which generates possible addresses. It must take a -single argument and output a list of possible matches, one per -line. - :type 'string +(defcustom notmuch-address-command nil + The command which generates possible addresses for completion. +It
Re: [PATCH v3] Emacs: Add address completion mechanism implemented in elisp
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.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. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [Patch v2 1/2] emacs: show: document the mark unread defcustom function
On Sat, Sep 06 2014, Mark Walters markwalters1...@gmail.com wrote: --- emacs/notmuch-show.el |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 7549fbb..5695d95 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -224,7 +224,13 @@ For example, if you wanted to remove an \unread\ tag and add a :group 'notmuch-show) (defcustom notmuch-show-mark-read-function #'notmuch-show-seen-current-message - Function to control which messages are marked read. + Function to control which messages are marked read. + +The function should take two arguments START and END which will +be the start and end of the visible portion of the buffer and +should mark the appropriate messages read by applying +`notmuch-show-mark-read'. This function will be called after +every user interaction with notmuch. This patch LGTM. Now that we know more I would have liked this function would not take the START END parameters but the function itself could have done (window-start) (window-end) if it so desires... ... as we have discussed in IRC my current version uses (point) in place of END (window-end) and I may drop START too (while investigating Mark's IRC-given suggestions). Anyway, the ship may have sailed and therefore I am inclined to give +1 to this patch... Tomi :type 'function :group 'notmuch-show) -- 1.7.10.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
