[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter

2011-06-04 Thread Daniel Schoepe
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

2011-06-04 Thread Daniel Schoepe
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] emacs: Tab completion for notmuch-search and notmuch-search-filter

2011-06-04 Thread Austin Clements
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.


[PATCH] fix sum moar typos

2011-06-04 Thread Pieter Praet
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?

2011-06-04 Thread Xavier Maillard
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


When will we have our next release?

2011-06-04 Thread Xavier Maillard
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?

2011-06-04 Thread David Bremner
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

2011-06-04 Thread Daniel Schoepe
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



[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter

2011-06-04 Thread Daniel Schoepe
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] Added C-up and C-down to cycle through previous searches

2011-06-04 Thread Dima Kogan
> 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

2011-06-04 Thread Austin Clements
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).


When will we have our next release?

2011-06-04 Thread David Bremner

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


[PATCH 14/25] Fix old style notmuch-fcc-dirs configuration check.

2011-06-04 Thread Dmitry Kurochkin
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


Re: When will we have our next release?

2011-06-04 Thread Xavier Maillard
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?

2011-06-04 Thread Xavier Maillard
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

2011-06-04 Thread Austin Clements
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?

2011-06-04 Thread David Bremner
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

2011-06-04 Thread Daniel Schoepe
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] Added C-up and C-down to cycle through previous searches

2011-06-04 Thread Dima Kogan
 On Sun, 29 May 2011 20:04:00 +0400
 Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote:

 Hi Dima.
 
 On Sun, 29 May 2011 01:56:28 -0700, notm...@dima.secretsauce.net
 wrote:
  From: Dima Kogan d...@secretsauce.net
  
  ---
  
   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?

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter

2011-06-04 Thread Daniel Schoepe
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

2011-06-04 Thread Austin Clements
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

2011-06-04 Thread Daniel Schoepe
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