Re: When will we have our next release?
Hi Carl, On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth cwo...@cworth.org wrote: On Fri, 03 Jun 2011 14:39:13 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Can we set a target date for 0.6 release? So we'll all start feeling really bad if we miss it? Frankly, I wouldn't mind doing strict time-based releases with something like the following: * We schedule a release period (once per month?) That sounds reasonable to me. You could even do it less frequently -i.e. every 2 month. * At the beginning of the safety period, package up the head of the notmuch tree and upload to Debian experimental and anywhere else similar. I like this idea. I already have slackware packages for notmuch and that's the way I prefer testing notmuch since I am not really comfortable with the git machinery (I wish I could do something for notmuch though). So switching to a more strictly time-based cycle can definitely help, (so many other projects use time-based releases very successfully). +1. THat's pretty frustating to contemplate all those patches/source code sent to this list and not being able to test them :) Whatever we choose, keep up the good work guys ! /Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: When will we have our next release?
Hi, On Sat, 04 Jun 2011 10:21:00 -0300, David Bremner brem...@unb.ca wrote: Overall I think Carl's time based release proposal is a reasonable plan. I think one problem we've been having is that we seem to have lost track of # Releases of notmuch have a two-digit version (0.1, 0.2, etc.). We # increment the second digit for each release and increment the first # digit when we reach particularly major milestones of usability. In short, I think we are make too big of a deal out of releases. Looking at the log between 0.5 and now, there are features enough to justify several minor releases. Or even major ! Frankly, this project has grew up quite quickly and features are implemented at a really good rythm. The sole problem is that it is really hard to see how far we are from a release and what exactly has been cooked up since latest release (from my point of view). On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth cwo...@cworth.org wrote: Frankly, I wouldn't mind doing strict time-based releases with something like the following: * We schedule a release period (once per month?) I think every two months might be a bit more comfortable, but then again, 1 month would keep us from making a big deal out of releases. Best before choosing the frequency is probably to try doing this a few times and be comfortable with the process. If after a few releases -i.e. say 3- the more we can do is release every trimester so do it. The process should be simple (and will be I guess) and the most difficult part is probably to document every aspect of every changes in the NEWS file (with eventually a good shaped manual ;)). * We schedule a safety period before the release (one week?) * At the beginning of the safety period, package up the head of the notmuch tree and upload to Debian experimental and anywhere else similar. Sure. I don't mind doing that part, at least for Debian. I'm going to try to do at roughly weekly uploads to Debian experimental. Hopefully this will get some critical mass of users testing those versions. I know it is a bit off topic here but just a question: how will you deal with dependencies ? I mean, when we need GMime vX.Y.Z and Debian has already vX.V.W ? /Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
Nifty! On Sat, Jun 4, 2011 at 8:19 AM, Daniel Schoepe daniel.scho...@googlemail.com wrote: + (minibuffer-completion-table (completion-table-dynamic + `(lambda (s) (notmuch-query-completions + (quote ,all-compls) s) + ;; ^ emulate a closure to avoid recomputing the completion list each time Dynamic scoping is obnoxious, but I think programmed completion is steeped in the assumption that you'll use it. This code would be much simpler if notmuch-query-completions took only `string' and used the dynamically-bound all-compls (which should probably be renamed notmuch-completions or something if you do this). Then this could be just (minibuffer-completion-table (completion-table-dynamic #'notmuch-query-completions))) and there'd be no need for quasiquoting, comments, and fake lexical scoping. +(define-key keymap (kbd tab) 'minibuffer-complete) This probably deserves a comment about why you're doing so much work to avoid completing-read (which I assume is because it also binds SPC, even if require-match is nil, which is unfortunate). ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: When will we have our next release?
On Sat, 04 Jun 2011 16:27:33 +0200, Xavier Maillard xav...@maillard.im wrote: I know it is a bit off topic here but just a question: how will you deal with dependencies ? I mean, when we need GMime vX.Y.Z and Debian has already vX.V.W ? The same as every other Debian package? Try to persuade the maintainer followed by uploading the new version ourselves if we run out of patience. To bring it back on topic (softof) I don't think anyone is suggesting that the Debian packaging be any kind of gatekeeper in the release process. I believe it is just that several of the people involved are also involved with Debian, and tend to think Debian uploads as a natural outcome of releasing software. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
On Sat, 4 Jun 2011 11:32:15 -0400, Austin Clements amdra...@mit.edu wrote:
Dynamic scoping is obnoxious, but I think programmed completion is
steeped in the assumption that you'll use it. This code would be much
simpler if notmuch-query-completions took only `string' and used the
dynamically-bound all-compls (which should probably be renamed
notmuch-completions or something if you do this). Then this could be
just
(minibuffer-completion-table (completion-table-dynamic
#'notmuch-query-completions)))
and there'd be no need for quasiquoting, comments, and fake lexical scoping.
Sounds reasonable, I guess I really should stop fighting all those ugly
parts of elisp with unreadable constructs like that. I made it a global
variable though to avoid compilation warnings about notmuch-completion
being a free variable. Since it's contents are not dependent on
how/where notmuch-read-query is called, this shouldn't cause any
problems, except my personal discomfort arising from the use of side
effects for something as simple as this. :)
+(define-key keymap (kbd tab) 'minibuffer-complete)
This probably deserves a comment about why you're doing so much work
to avoid completing-read (which I assume is because it also binds SPC,
even if require-match is nil, which is unfortunate).
Yes, that was the reason.
Another thing that bugs me, is that I did not find a better way of doing
the completion: Ideally I'd like to just specify a list of completions
for individual words and have emacs handle separating the input string
into individual words, but I couldn't find any options to accomplish
that.
An updated patch is attached.
From 70642aecbf63428d9bcedc108c55f65574a792e7 Mon Sep 17 00:00:00 2001
From: Daniel Schoepe daniel.scho...@googlemail.com
Date: Sat, 4 Jun 2011 14:17:44 +0200
Subject: [PATCH] emacs: Tab completion for notmuch-search and
notmuch-search-filter
This patch adds completion with tab in the minibuffer for
notmuch-search and notmuch-search-filter.
---
emacs/notmuch.el | 35 +--
1 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 3311fe8..17c214c 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -72,6 +72,9 @@ For example:
:type '(alist :key-type (string) :value-type (string))
:group 'notmuch)
+(defvar notmuch-completions nil
+ List of completions used in notmuch-query-completions)
+
(defun notmuch-select-tag-with-completion (prompt rest search-terms)
(let ((tag-list
(with-output-to-string
@@ -882,6 +885,34 @@ characters as well as `_.+-'.
(concat *notmuch-search- query *))
)))
+(defun notmuch-query-completions (string)
+ Return possible completions for STRING.
+ (cond
+ ;; this ugly regexp is used to get the last word of the input
+ ;; possibly preceded by a '('
+ ((string-match \\(^\\|.* (?\\)\\([^ ]*\\)$ string)
+(mapcar (lambda (compl)
+ (concat (match-string-no-properties 1 string) compl))
+ (all-completions (match-string-no-properties 2 string)
+ notmuch-completions)))
+ (t (list string
+
+(defun notmuch-read-query (prompt)
+ Read a notmuch-query from the minibuffer with completion.
+
+PROMPT is the string to prompt with.
+ (let ((keymap (copy-keymap minibuffer-local-map))
+ (minibuffer-completion-table (completion-table-dynamic #'notmuch-query-completions)))
+;; this was simpler than convincing completing-read to accept spaces:
+(define-key keymap (kbd tab) 'minibuffer-complete)
+(setq notmuch-completions
+ (append (list folder: thread: id: date: from: to:
+ subject: attachment:)
+ (mapcar (lambda (tag)
+ (concat tag: tag))
+ (process-lines notmuch search-tags
+(read-from-minibuffer prompt nil keymap nil minibuffer-history nil nil)))
+
;;;###autoload
(defun notmuch-search (query optional oldest-first target-thread target-line continuation)
Run \notmuch search\ with the given query string and display results.
@@ -893,7 +924,7 @@ The optional parameters are used as follows:
current if it appears in the search results.
target-line: The line number to move to if the target thread does not
appear in the search results.
- (interactive sNotmuch search: )
+ (interactive (notmuch-read-query Notmuch search: ))
(let ((buffer (get-buffer-create (notmuch-search-buffer-title query
(switch-to-buffer buffer)
(notmuch-search-mode)
@@ -991,7 +1022,7 @@ search.
Runs a new search matching only messages that match both the
current search results AND the additional query string provided.
- (interactive sFilter search: )
+ (interactive (notmuch-read-query Filter search: ))
(let ((grouped-query (if (string-match-p notmuch-search-disjunctive-regexp query)
(concat ( query ))
query)))
--
1.7.5.3
pgpZUqPb2jMu2.pgp
Description: PGP signature
___
notmuch mailing list
Re: [PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
Sorry, forgot to actually test notmuch-search entirely with this change
and not just the completion.
From cb172efc1dea2507566db587f960c073373e0159 Mon Sep 17 00:00:00 2001
From: Daniel Schoepe daniel.scho...@googlemail.com
Date: Sat, 4 Jun 2011 14:17:44 +0200
Subject: [PATCH] emacs: Tab completion for notmuch-search and
notmuch-search-filter
This patch adds completion with tab in the minibuffer for
notmuch-search and notmuch-search-filter.
---
emacs/notmuch.el | 35 +--
1 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 3311fe8..a2db852 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -72,6 +72,9 @@ For example:
:type '(alist :key-type (string) :value-type (string))
:group 'notmuch)
+(defvar notmuch-completions nil
+ List of completions used in notmuch-query-completions)
+
(defun notmuch-select-tag-with-completion (prompt rest search-terms)
(let ((tag-list
(with-output-to-string
@@ -882,6 +885,34 @@ characters as well as `_.+-'.
(concat *notmuch-search- query *))
)))
+(defun notmuch-query-completions (string)
+ Return possible completions for STRING.
+ (cond
+ ;; this ugly regexp is used to get the last word of the input
+ ;; possibly preceded by a '('
+ ((string-match \\(^\\|.* (?\\)\\([^ ]*\\)$ string)
+(mapcar (lambda (compl)
+ (concat (match-string-no-properties 1 string) compl))
+ (all-completions (match-string-no-properties 2 string)
+ notmuch-completions)))
+ (t (list string
+
+(defun notmuch-read-query (prompt)
+ Read a notmuch-query from the minibuffer with completion.
+
+PROMPT is the string to prompt with.
+ (let ((keymap (copy-keymap minibuffer-local-map))
+ (minibuffer-completion-table (completion-table-dynamic #'notmuch-query-completions)))
+;; this was simpler than convincing completing-read to accept spaces:
+(define-key keymap (kbd tab) 'minibuffer-complete)
+(setq notmuch-completions
+ (append (list folder: thread: id: date: from: to:
+ subject: attachment:)
+ (mapcar (lambda (tag)
+ (concat tag: tag))
+ (process-lines notmuch search-tags
+(read-from-minibuffer prompt nil keymap nil minibuffer-history nil nil)))
+
;;;###autoload
(defun notmuch-search (query optional oldest-first target-thread target-line continuation)
Run \notmuch search\ with the given query string and display results.
@@ -893,7 +924,7 @@ The optional parameters are used as follows:
current if it appears in the search results.
target-line: The line number to move to if the target thread does not
appear in the search results.
- (interactive sNotmuch search: )
+ (interactive (list (notmuch-read-query Notmuch search: )))
(let ((buffer (get-buffer-create (notmuch-search-buffer-title query
(switch-to-buffer buffer)
(notmuch-search-mode)
@@ -991,7 +1022,7 @@ search.
Runs a new search matching only messages that match both the
current search results AND the additional query string provided.
- (interactive sFilter search: )
+ (interactive (list (notmuch-read-query Filter search: )))
(let ((grouped-query (if (string-match-p notmuch-search-disjunctive-regexp query)
(concat ( query ))
query)))
--
1.7.5.3
pgpPRWlpziEvE.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
Quoth Daniel Schoepe on Jun 04 at 9:55 pm:
On Sat, 4 Jun 2011 11:32:15 -0400, Austin Clements amdra...@mit.edu wrote:
Dynamic scoping is obnoxious, but I think programmed completion is
steeped in the assumption that you'll use it. This code would be much
simpler if notmuch-query-completions took only `string' and used the
dynamically-bound all-compls (which should probably be renamed
notmuch-completions or something if you do this). Then this could be
just
(minibuffer-completion-table (completion-table-dynamic
#'notmuch-query-completions)))
and there'd be no need for quasiquoting, comments, and fake lexical scoping.
Sounds reasonable, I guess I really should stop fighting all those ugly
parts of elisp with unreadable constructs like that. I made it a global
variable though to avoid compilation warnings about notmuch-completion
being a free variable. Since it's contents are not dependent on
how/where notmuch-read-query is called, this shouldn't cause any
problems, except my personal discomfort arising from the use of side
effects for something as simple as this. :)
Oh, sorry, I wasn't suggesting setq'ing a global. I agree that that's
really ugly. Rather, something like
(defun notmuch-query-completions (string)
... as you have it now ...)
(defun notmuch-read-query (prompt)
(let ((notmuch-completions (append (list folder: ...)))
(keymap ...)
(minibuffer-completion-table ...))
(read-from-minibuffer ...)))
Unfortunately, you still need the global defvar to avoid compilation
warnings, but this at least avoids the side-effects, and is probably
how programmed completion was intended to be used.
Alternatively, here's a completely different way to structure this
that avoids globals and dynamic scoping entirely. This is how some of
the standard completing read functions appear to work:
(defun notmuch-read-query (prompt)
Read a notmuch-query from the minibuffer with completion.
PROMPT is the string to prompt with.
(lexical-let ((completions
(append (list folder: thread: id: date: from: to:
subject: attachment:)
(mapcar (lambda (tag)
(concat tag: tag))
(process-lines notmuch search-tags)
(let ((minibuffer-completion-table
(completion-table-dynamic
(lambda (string)
(cond
;; this ugly regexp is used to get the last word of the
;; input possibly preceded by a '('
((string-match \\(^\\|.* (?\\)\\([^ ]*\\)$ string)
(mapcar (lambda (compl)
(concat (match-string-no-properties 1 string) compl))
(all-completions (match-string-no-properties 2 string)
completions)))
(t (list string))
(keymap (copy-keymap minibuffer-local-map)))
;; this was simpler than convincing completing-read to accept spaces:
(define-key keymap (kbd tab) 'minibuffer-complete)
(read-from-minibuffer prompt nil keymap nil minibuffer-history nil nil
+(define-key keymap (kbd tab) 'minibuffer-complete)
This probably deserves a comment about why you're doing so much work
to avoid completing-read (which I assume is because it also binds SPC,
even if require-match is nil, which is unfortunate).
Yes, that was the reason.
Another thing that bugs me, is that I did not find a better way of doing
the completion: Ideally I'd like to just specify a list of completions
for individual words and have emacs handle separating the input string
into individual words, but I couldn't find any options to accomplish
that.
Yeah, I futzed with it for a bit, swearing that there had to be a
better way, but didn't find one either.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
On Sat, 4 Jun 2011 17:55:24 -0400, Austin Clements amdra...@mit.edu wrote:
Oh, sorry, I wasn't suggesting setq'ing a global. I agree that that's
really ugly. Rather, something like
(defun notmuch-query-completions (string)
... as you have it now ...)
(defun notmuch-read-query (prompt)
(let ((notmuch-completions (append (list folder: ...)))
(keymap ...)
(minibuffer-completion-table ...))
(read-from-minibuffer ...)))
Unfortunately, you still need the global defvar to avoid compilation
warnings, but this at least avoids the side-effects, and is probably
how programmed completion was intended to be used.
Both alternatives seem about equally ugly to me, since the one using
dynamic scoping still uses side-effects, because it still passes the
completion information around without using it as an argument to
notmuch-query-completions. At least defvar-ing a global variable and
then never actually using it, seems somewhat unclean as well.
Alternatively, here's a completely different way to structure this
that avoids globals and dynamic scoping entirely. This is how some of
the standard completing read functions appear to work:
Ah right, I forgot that using macros from cl is fine even in library
code.
From 7768f41ac44213c5e2c1dc3b0f13e3edf1d97a26 Mon Sep 17 00:00:00 2001
From: Daniel Schoepe daniel.scho...@googlemail.com
Date: Sat, 4 Jun 2011 14:17:44 +0200
Subject: [PATCH] emacs: Tab completion for notmuch-search and
notmuch-search-filter
This patch adds completion with tab in the minibuffer for
notmuch-search and notmuch-search-filter.
---
emacs/notmuch.el | 36 ++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 3311fe8..33c34bd 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -72,6 +72,9 @@ For example:
:type '(alist :key-type (string) :value-type (string))
:group 'notmuch)
+(defvar notmuch-completions nil
+ List of completions used in notmuch-query-completions)
+
(defun notmuch-select-tag-with-completion (prompt rest search-terms)
(let ((tag-list
(with-output-to-string
@@ -882,6 +885,35 @@ characters as well as `_.+-'.
(concat *notmuch-search- query *))
)))
+(defun notmuch-read-query (prompt)
+ Read a notmuch-query from the minibuffer with completion.
+
+PROMPT is the string to prompt with.
+ (lexical-let
+ ((completions
+ (append (list folder: thread: id: date: from: to:
+ subject: attachment:)
+ (mapcar (lambda (tag)
+ (concat tag: tag))
+ (process-lines notmuch search-tags)
+(let ((keymap (copy-keymap minibuffer-local-map))
+ (minibuffer-completion-table
+ (completion-table-dynamic
+ (lambda (string)
+ ;; generate a list of possible completions for the current input
+ (cond
+ ;; this ugly regexp is used to get the last word of the input
+ ;; possibly preceded by a '('
+ ((string-match \\(^\\|.* (?\\)\\([^ ]*\\)$ string)
+ (mapcar (lambda (compl)
+ (concat (match-string-no-properties 1 string) compl))
+ (all-completions (match-string-no-properties 2 string)
+ completions)))
+ (t (list string)))
+ ;; this was simpler than convincing completing-read to accept spaces:
+ (define-key keymap (kbd tab) 'minibuffer-complete)
+ (read-from-minibuffer prompt nil keymap nil minibuffer-history nil nil
+
;;;###autoload
(defun notmuch-search (query optional oldest-first target-thread target-line continuation)
Run \notmuch search\ with the given query string and display results.
@@ -893,7 +925,7 @@ The optional parameters are used as follows:
current if it appears in the search results.
target-line: The line number to move to if the target thread does not
appear in the search results.
- (interactive sNotmuch search: )
+ (interactive (list (notmuch-read-query Notmuch search: )))
(let ((buffer (get-buffer-create (notmuch-search-buffer-title query
(switch-to-buffer buffer)
(notmuch-search-mode)
@@ -991,7 +1023,7 @@ search.
Runs a new search matching only messages that match both the
current search results AND the additional query string provided.
- (interactive sFilter search: )
+ (interactive (list (notmuch-read-query Filter search: )))
(let ((grouped-query (if (string-match-p notmuch-search-disjunctive-regexp query)
(concat ( query ))
query)))
--
1.7.5.3
pgpjYvXqoOxMf.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 14/25] Fix old style notmuch-fcc-dirs configuration check.
On Fri, 03 Jun 2011 13:05:00 -0700, Carl Worth wrote: Non-text part: multipart/signed > On Thu, 02 Jun 2011 10:49:57 +0400, Dmitry Kurochkin gmail.com> wrote: > > Well, it says that changes are in notmuch 0.5. So "old" and "previous" > > refer to pre-0.5 (i.e. 0.4) and "new" refers to 0.5. > > Sure, but I happen to ahve already forgotten the details of how the > variable could be configured in 0.4 and in 0.5. More importantly, anyone > in the future reading the commit log is much more likely not to > remember. > > > Any configuration when `notmuch-fcc-dirs' is a list. That variable has > > a nice documentation. > > Again, I'd like our commit messages to be self-contained. They are much > more useful if the describe the change being made without assuming to > much outside knowledge. > > > > It would be easier to understand the code if there were a corresponding > > > test case for it. > ... > > I do not think we need a test for this fix. What we need are tests for > > FCC functionality when notmuch-fcc-dirs is a list. > > Yes! > > > Old configuration format was changed in 0.5 in an incompatible way. > > There is a check for the unsupported old-style configuration. But the > > check is broken and results in an error when running with a valid > > new-style configuration. > > This is actually what I meant by "corresponding test case". If the bug > here is that a "new-style configuration" doesn't work , (and I still > don't like that wording---don't say "new style"---explain what it > actually *is*), then yes, we need a test case showing that bug. > > > I am not sure what you expect from the commit message here. IMO it is > > enough for this small bugfix and those who interested can always refer > > to documentation for details. > > The commit message should provide a self-contained description of the > change. It should be along the lines of: > > When fcc-dirs is set to >notmuch was > incorecctly detecting this as the >and generating an error > message. Fix the test so that this configuration now works. > > Where the above should be replaced with actual descriptions, > not relative pointers to information like "old style" or "new style". > > Does that make sense? > "notmuch was incorecctly detecting this as the ..." is not right. It is a wrong-type-argument lisp error (evaluating (length '(a . b))). How about: Fix wrong-type-argument lisp error in `notmuch-fcc-header-setup' when `notmuch-fcc-dirs' is set to a list. The error was in the `notmuch-fcc-dirs' format check which was changed in an incompatible way from 0.4 to 0.5. Regards, Dmitry > -Carl Non-text part: application/pgp-signature
[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
This patch adds completion with in the minibuffer for notmuch-search and notmuch-search-filter. --- emacs/notmuch.el | 33 +++-- 1 files changed, 31 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 3311fe8..49a82be 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -882,6 +882,35 @@ characters as well as `_.+-'. (concat "*notmuch-search-" query "*")) ))) +(defun notmuch-query-completions (compls string) + "Return possible completions for STRING. + +COMPLS should be a list of possibilities for an individual word." + (cond + ((string-match "\\(^\\|.* (?\\)\\([^ ]*\\)$" string) +(mapcar (lambda (compl) + (concat (match-string-no-properties 1 string) compl)) + (all-completions (match-string-no-properties 2 string) +compls))) + (t (list string + +(defun notmuch-read-query (prompt) + "Read a notmuch-query from the minibuffer with completion. + +PROMPT is the string to prompt with." + (let* ((keymap (copy-keymap minibuffer-local-map)) +(all-compls (append (list "folder:" "thread:" "id:" "date:" "from:" + "to:" "subject:" "attachment:") +(mapcar (lambda (tag) + (concat "tag:" tag)) +(process-lines "notmuch" "search-tags"))) +(minibuffer-completion-table (completion-table-dynamic + `(lambda (s) (notmuch-query-completions + (quote ,all-compls) s) +;; ^ emulate a closure to avoid recomputing the completion list each time +(define-key keymap (kbd "") 'minibuffer-complete) +(read-from-minibuffer prompt nil keymap nil minibuffer-history nil nil))) + ;;;###autoload (defun notmuch-search (query oldest-first target-thread target-line continuation) "Run \"notmuch search\" with the given query string and display results. @@ -893,7 +922,7 @@ The optional parameters are used as follows: current if it appears in the search results. target-line: The line number to move to if the target thread does not appear in the search results." - (interactive "sNotmuch search: ") + (interactive (notmuch-read-query "Notmuch search: ")) (let ((buffer (get-buffer-create (notmuch-search-buffer-title query (switch-to-buffer buffer) (notmuch-search-mode) @@ -991,7 +1020,7 @@ search." Runs a new search matching only messages that match both the current search results AND the additional query string provided." - (interactive "sFilter search: ") + (interactive (notmuch-read-query "Filter search: ")) (let ((grouped-query (if (string-match-p notmuch-search-disjunctive-regexp query) (concat "( " query " )") query))) -- 1.7.5.3
[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
This patch adds completion with in the minibuffer for notmuch-search and notmuch-search-filter. --- emacs/notmuch.el | 33 +++-- 1 files changed, 31 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 3311fe8..7b63dc9 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -882,6 +882,35 @@ characters as well as `_.+-'. (concat "*notmuch-search-" query "*")) ))) +(defun notmuch-query-completions (compls string) + "Return possible completions for STRING. + +COMPLS should be a list of possibilities for an individual word." + (cond + ((string-match "\\(^\\|.* (?\\)\\([^ ]*\\)$" string) +(mapcar (lambda (compl) + (concat (match-string-no-properties 1 string) compl)) + (all-completions (match-string-no-properties 2 string) +compls))) + (t (list string + +(defun notmuch-read-query (prompt) + "Read a notmuch-query from the minibuffer with completion. + +PROMPT is the string to prompt with." + (let* ((keymap (copy-keymap minibuffer-local-map)) +(all-compls (append (list "folder:" "thread:" "id:" "date:" "from:" + "to:" "subject:" "attachment:") +(mapcar (lambda (tag) + (concat "tag:" tag)) +(process-lines "notmuch" "search-tags" +(minibuffer-completion-table (completion-table-dynamic + `(lambda (s) (notmuch-query-completions + (quote ,all-compls) s) +;; ^ emulate a closure to avoid recomputing the completion list each time +(define-key keymap (kbd "") 'minibuffer-complete) +(read-from-minibuffer prompt nil keymap nil minibuffer-history nil nil))) + ;;;###autoload (defun notmuch-search (query oldest-first target-thread target-line continuation) "Run \"notmuch search\" with the given query string and display results. @@ -893,7 +922,7 @@ The optional parameters are used as follows: current if it appears in the search results. target-line: The line number to move to if the target thread does not appear in the search results." - (interactive "sNotmuch search: ") + (interactive (notmuch-read-query "Notmuch search: ")) (let ((buffer (get-buffer-create (notmuch-search-buffer-title query (switch-to-buffer buffer) (notmuch-search-mode) @@ -991,7 +1020,7 @@ search." Runs a new search matching only messages that match both the current search results AND the additional query string provided." - (interactive "sFilter search: ") + (interactive (notmuch-read-query "Filter search: ")) (let ((grouped-query (if (string-match-p notmuch-search-disjunctive-regexp query) (concat "( " query " )") query))) -- 1.7.5.3
When will we have our next release?
Overall I think Carl's time based release proposal is a reasonable plan. I think one problem we've been having is that we seem to have lost track of # Releases of notmuch have a two-digit version (0.1, 0.2, etc.). We # increment the second digit for each release and increment the first # digit when we reach particularly major milestones of usability. In short, I think we are make too big of a deal out of releases. Looking at the log between 0.5 and now, there are features enough to justify several minor releases. On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth wrote: > > Frankly, I wouldn't mind doing strict time-based releases with something > like the following: > > * We schedule a release period (once per month?) I think every two months might be a bit more comfortable, but then again, 1 month would keep us from "making a big deal out of releases." > * We schedule a "safety period" before the release (one week?) > * At the beginning of the safety period, package up the head > of the notmuch tree and upload to Debian experimental and > anywhere else similar. Sure. I don't mind doing that part, at least for Debian. I'm going to try to do at roughly weekly uploads to Debian experimental. Hopefully this will get some critical mass of users testing those versions. d
When will we have our next release?
Hi Carl, On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth wrote: > On Fri, 03 Jun 2011 14:39:13 -0700, Jameson Graef Rollins finestructure.net> wrote: > > Can we set a target date for 0.6 release? So we'll all start feeling > > really bad if we miss it? > > Frankly, I wouldn't mind doing strict time-based releases with something > like the following: > > * We schedule a release period (once per month?) That sounds reasonable to me. You could even do it less frequently -i.e. every 2 month. > * At the beginning of the safety period, package up the head > of the notmuch tree and upload to Debian experimental and > anywhere else similar. I like this idea. I already have slackware packages for notmuch and that's the way I prefer testing notmuch since I am not really comfortable with the git machinery (I wish I could do something for notmuch though). > So switching to a more strictly time-based cycle can definitely help, > (so many other projects use time-based releases very successfully). +1. THat's pretty frustating to contemplate all those patches/source code sent to this list and not being able to "test" them :) Whatever we choose, keep up the good work guys ! /Xavier
When will we have our next release?
Hi, On Sat, 04 Jun 2011 10:21:00 -0300, David Bremner wrote: > Overall I think Carl's time based release proposal is a reasonable > plan. I think one problem we've been having is that we seem to have lost > track of > > # Releases of notmuch have a two-digit version (0.1, 0.2, etc.). We > # increment the second digit for each release and increment the first > # digit when we reach particularly major milestones of usability. > > In short, I think we are make too big of a deal out of releases. Looking > at the log between 0.5 and now, there are features enough to justify > several minor releases. Or even major ! Frankly, this project has grew up quite quickly and features are implemented at a really good rythm. The sole problem is that it is really hard to see how far we are from a release and what exactly has been cooked up since latest release (from my point of view). > On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth wrote: > > > > Frankly, I wouldn't mind doing strict time-based releases with something > > like the following: > > > > * We schedule a release period (once per month?) > > I think every two months might be a bit more comfortable, but then > again, 1 month would keep us from "making a big deal out of releases." Best before choosing the frequency is probably to try doing this a few times and be comfortable with the process. If after a few releases -i.e. say 3- the more we can do is release every trimester so do it. The process should be simple (and will be I guess) and the most difficult part is probably to document every aspect of every changes in the NEWS file (with eventually a good shaped manual ;)). > > * We schedule a "safety period" before the release (one week?) > > * At the beginning of the safety period, package up the head > > of the notmuch tree and upload to Debian experimental and > > anywhere else similar. > > Sure. I don't mind doing that part, at least for Debian. I'm going to > try to do at roughly weekly uploads to Debian experimental. Hopefully > this will get some critical mass of users testing those versions. I know it is a bit off topic here but just a question: how will you deal with dependencies ? I mean, when we need GMime vX.Y.Z and Debian has already vX.V.W ? /Xavier
[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
Nifty! On Sat, Jun 4, 2011 at 8:19 AM, Daniel Schoepe wrote: > + ? ? ? ?(minibuffer-completion-table (completion-table-dynamic > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?`(lambda (s) (notmuch-query-completions > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (quote ,all-compls) s) > + ? ?;; ^ emulate a closure to avoid recomputing the completion list each time Dynamic scoping is obnoxious, but I think programmed completion is steeped in the assumption that you'll use it. This code would be much simpler if notmuch-query-completions took only `string' and used the dynamically-bound all-compls (which should probably be renamed notmuch-completions or something if you do this). Then this could be just (minibuffer-completion-table (completion-table-dynamic #'notmuch-query-completions))) and there'd be no need for quasiquoting, comments, and fake lexical scoping. > +(define-key keymap (kbd "") 'minibuffer-complete) This probably deserves a comment about why you're doing so much work to avoid completing-read (which I assume is because it also binds SPC, even if require-match is nil, which is unfortunate).
[PATCH] fix sum moar typos
Because they cause global warming.
Signed-off-by: Pieter Praet
---
TL;DR: Various typo fixes. Applies to jrollins/release-candidate/0.6 (2baf08f5)
Due to the impending 0.6 release, I've gone off on an ephemeral typo hunt,
and have brought back some trophies.
As it's such an utterly amusing passtime, I've been pretty fat-fingered about
it,
and wouldn't be surprised if I've missed some, or even made some new ones.
Nonetheless: Lets maek 0.6 purrfec!
NEWS | 10 +-
TODO |4 ++--
compat/README|2 +-
completion/Makefile |2 +-
configure|4 ++--
emacs/Makefile |2 +-
emacs/notmuch-crypto.el |2 +-
emacs/notmuch-hello.el |2 +-
emacs/notmuch-lib.el |2 +-
emacs/notmuch-maildir-fcc.el |2 +-
emacs/notmuch-show.el|6 +++---
emacs/notmuch-wash.el|2 +-
emacs/notmuch.el |6 +++---
gmime-filter-headers.h |2 +-
lib/Makefile |2 +-
lib/Makefile.local |2 +-
lib/database.cc | 12 ++--
lib/libsha1.c|2 +-
lib/libsha1.h|2 +-
lib/message.cc |4 ++--
lib/notmuch.h|4 ++--
notmuch-config.c |2 +-
notmuch-new.c|2 +-
notmuch-reply.c |4 ++--
notmuch.1|6 +++---
notmuch.c|2 +-
packaging/debian |4 ++--
test/Makefile|2 +-
test/README |6 +++---
test/crypto |2 +-
test/maildir-sync|2 +-
test/multipart |2 +-
test/test-lib.sh |2 +-
test/uuencode|4 ++--
vim/README |2 +-
vim/plugin/notmuch.vim |4 ++--
36 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/NEWS b/NEWS
index 5a1778e..dae7832 100644
--- a/NEWS
+++ b/NEWS
@@ -112,15 +112,15 @@ Allow for notmuch-fcc-dirs to have a value of nil.
string. Instead it's now a list of cons cells where the car of each
cell is a regular expression to be matched against the sender
address, and the cdr is the name of a folder to use for an FCC. So
- the old fallback behavior can be achieved by including a fineal cell
+ the old fallback behavior can be achieved by including a final cell
of (".*" . "default-fcc-folder").
Vim interface improvements
--
Felipe Contreras provided a number of updates for the vim interface.
- These include optimiations, support for newer versions of vim, fixed
- support for sending mail on modern systmms, new commands, and
+ These include optimizations, support for newer versions of vim, fixed
+ support for sending mail on modern systems, new commands, and
various cleanups.
New bindings
@@ -606,7 +606,7 @@ Fix to compile against GMime 2.6
Fix configure script to accept (and ignore) various standard options.
- For example, those that the gentoo build scripts expect configure to
+ For example, those that the Gentoo build scripts expect configure to
accept are now all accepted.
Test suite
@@ -714,7 +714,7 @@ tags by region.
Selective bulk tagging is now possible by selecting a region of
threads and then using either the '+' or '-' keybindings. Bulk
tagging is still available for all threads matching the current
- search with th '*' binding.
+ search with the '*' binding.
More meaningful buffer names for thread-view buffers.
diff --git a/TODO b/TODO
index 260ffe1..14dfa55 100644
--- a/TODO
+++ b/TODO
@@ -29,7 +29,7 @@ Make 'notmuch-show-pipe-message have a private history.
Add support for a delete keybinding that adds a "deleted" tag to the
current message/thread and make searches not return deleted messages
-by default, (unless the user asks explicitly for deleted messags in
+by default, (unless the user asks explicitly for deleted messages in
the search query).
Add keybindings for next/previous thread.
@@ -119,7 +119,7 @@ Allow configuration for filename patterns that should be
ignored when
indexing.
Replace the "notmuch part --part=id" command with "notmuch show
---part=id", (David Edmonson wants to rewrite some of "notmuch show" to
+--part=id", (David Edmondson wants to rewrite some of "notmuch show" to
provide more MIME-structure information in its output first).
Replace the "notmuch search-tags" command with "notmuch search
diff --git a/compat/README b/compat/README
index cd32c56..38e2e14 100644
--- a/compat/README
+++ b/compat/README
@@ -1,4 +1,4 @@
-notmuch/comapt
+notmuch/compat
This directory consists of two things:
diff --git a/completion/Makefile b/completion/Makefile
index b6859ea..de492a7 100644
--- a/completion/Makefile
+++ b/completion/Makefile
@@ -1,4 +1,4 @@
-# See Makfefile.local for the list of files to be
When will we have our next release?
On Sat, 04 Jun 2011 16:27:33 +0200, Xavier Maillard wrote: > I know it is a bit off topic here but just a question: how will you deal > with dependencies ? I mean, when we need GMime vX.Y.Z and Debian has > already vX.V.W ? The same as every other Debian package? Try to persuade the maintainer followed by uploading the new version ourselves if we run out of patience. To bring it back on topic (softof) I don't think anyone is suggesting that the Debian packaging be any kind of gatekeeper in the release process. I believe it is just that several of the people involved are also involved with Debian, and tend to think Debian uploads as a natural outcome of releasing software. d
[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
On Sat, 4 Jun 2011 11:32:15 -0400, Austin Clements wrote: > Dynamic scoping is obnoxious, but I think programmed completion is > steeped in the assumption that you'll use it. This code would be much > simpler if notmuch-query-completions took only `string' and used the > dynamically-bound all-compls (which should probably be renamed > notmuch-completions or something if you do this). Then this could be > just > (minibuffer-completion-table (completion-table-dynamic > #'notmuch-query-completions))) > and there'd be no need for quasiquoting, comments, and fake lexical scoping. Sounds reasonable, I guess I really should stop fighting all those ugly parts of elisp with unreadable constructs like that. I made it a global variable though to avoid compilation warnings about notmuch-completion being a free variable. Since it's contents are not dependent on how/where notmuch-read-query is called, this shouldn't cause any problems, except my personal discomfort arising from the use of side effects for something as simple as this. :) > > +(define-key keymap (kbd "") 'minibuffer-complete) > > This probably deserves a comment about why you're doing so much work > to avoid completing-read (which I assume is because it also binds SPC, > even if require-match is nil, which is unfortunate). Yes, that was the reason. Another thing that bugs me, is that I did not find a better way of doing the completion: Ideally I'd like to just specify a list of completions for individual words and have emacs handle separating the input string into individual words, but I couldn't find any options to accomplish that. An updated patch is attached. -- next part -- A non-text attachment was scrubbed... Name: 0001-emacs-Tab-completion-for-notmuch-search-and-notmuch-.patch Type: text/x-diff Size: 3267 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110604/016d9e5b/attachment.patch> -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110604/016d9e5b/attachment.pgp>
[PATCH] Added C-up and C-down to cycle through previous searches
> On Sun, 29 May 2011 20:04:00 +0400 > Dmitry Kurochkin wrote: > > Hi Dima. > > On Sun, 29 May 2011 01:56:28 -0700, notmuch at dima.secretsauce.net > wrote: > > From: Dima Kogan > > > > --- > > > > Hi. > > > > I made a few improvements to the emacs UI. This patch allows the > > user to scroll through the most recent searches with C-up and > > C-down while in the search box. > > > > This sounds like a very nice improvement to me! I just have one > concern: Why C-up and C-down? I believe M-p and M-n would be more > natural for Emacs users (at least for me :)). > > Also, I did not read the code and can not comment on it. But notmuch > coding style is to use tabs for indentation. I guess .dir-locals.el > should be improved to set coding style variables for all modes, not > just C. > > Regards, > Dmitry Hi. I have a mild preference to C-up/down, but M-n/p is just fine also. As for the coding style, I've looked through that file (notmuch-hello.el), and it doesn't seem to have a consistent style as far as tabs/spaces go. I'm happy to change my patch to conform, but I don't know what I should be conforming to. Should I be tab-ing all indents, or just some?
[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
Sorry, forgot to actually test notmuch-search entirely with this change and not just the completion. -- next part -- A non-text attachment was scrubbed... Name: 0001-emacs-Tab-completion-for-notmuch-search-and-notmuch-.patch Type: text/x-diff Size: 3281 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110604/a1a7067a/attachment.patch> -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110604/a1a7067a/attachment.pgp>
[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
Quoth Daniel Schoepe on Jun 04 at 9:55 pm:
> On Sat, 4 Jun 2011 11:32:15 -0400, Austin Clements
> wrote:
> > Dynamic scoping is obnoxious, but I think programmed completion is
> > steeped in the assumption that you'll use it. This code would be much
> > simpler if notmuch-query-completions took only `string' and used the
> > dynamically-bound all-compls (which should probably be renamed
> > notmuch-completions or something if you do this). Then this could be
> > just
> > (minibuffer-completion-table (completion-table-dynamic
> > #'notmuch-query-completions)))
> > and there'd be no need for quasiquoting, comments, and fake lexical scoping.
>
> Sounds reasonable, I guess I really should stop fighting all those ugly
> parts of elisp with unreadable constructs like that. I made it a global
> variable though to avoid compilation warnings about notmuch-completion
> being a free variable. Since it's contents are not dependent on
> how/where notmuch-read-query is called, this shouldn't cause any
> problems, except my personal discomfort arising from the use of side
> effects for something as simple as this. :)
Oh, sorry, I wasn't suggesting setq'ing a global. I agree that that's
really ugly. Rather, something like
(defun notmuch-query-completions (string)
... as you have it now ...)
(defun notmuch-read-query (prompt)
(let ((notmuch-completions (append (list "folder:" ...)))
(keymap ...)
(minibuffer-completion-table ...))
(read-from-minibuffer ...)))
Unfortunately, you still need the global defvar to avoid compilation
warnings, but this at least avoids the side-effects, and is probably
how programmed completion was intended to be used.
Alternatively, here's a completely different way to structure this
that avoids globals and dynamic scoping entirely. This is how some of
the standard completing read functions appear to work:
(defun notmuch-read-query (prompt)
"Read a notmuch-query from the minibuffer with completion.
PROMPT is the string to prompt with."
(lexical-let ((completions
(append (list "folder:" "thread:" "id:" "date:" "from:" "to:"
"subject:" "attachment:")
(mapcar (lambda (tag)
(concat "tag:" tag))
(process-lines "notmuch" "search-tags")
(let ((minibuffer-completion-table
(completion-table-dynamic
(lambda (string)
(cond
;; this ugly regexp is used to get the last word of the
;; input possibly preceded by a '('
((string-match "\\(^\\|.* (?\\)\\([^ ]*\\)$" string)
(mapcar (lambda (compl)
(concat (match-string-no-properties 1 string) compl))
(all-completions (match-string-no-properties 2 string)
completions)))
(t (list string))
(keymap (copy-keymap minibuffer-local-map)))
;; this was simpler than convincing completing-read to accept spaces:
(define-key keymap (kbd "") 'minibuffer-complete)
(read-from-minibuffer prompt nil keymap nil minibuffer-history nil nil
> > > +(define-key keymap (kbd "") 'minibuffer-complete)
> >
> > This probably deserves a comment about why you're doing so much work
> > to avoid completing-read (which I assume is because it also binds SPC,
> > even if require-match is nil, which is unfortunate).
>
> Yes, that was the reason.
>
> Another thing that bugs me, is that I did not find a better way of doing
> the completion: Ideally I'd like to just specify a list of completions
> for individual words and have emacs handle separating the input string
> into individual words, but I couldn't find any options to accomplish
> that.
Yeah, I futzed with it for a bit, swearing that there had to be a
better way, but didn't find one either.
