(no subject)

[Matt Armstrong]

This supercedes
id:1476207707-21827-1-git-send-email-marmstrong@google.com with
changes steming from Mark's helpful feedback.

[PATCH v3] Add notmuch-show--build-queries.

[Matt Armstrong]

notmuch-show--build-buffer now queries a list of queries built by the
former.  This simplifies the logic.  It also provides an easy place to
experiment with alternate sets of queries for given notmuch-show-*
variables (e.g. users can use advice-add to do so in a surgical way).
---
 emacs/notmuch-show.el | 36 ++++++++++++++++++++++--------------
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f2487ab..b393c11 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1261,6 +1261,20 @@ matched."
 	(message "No messages matched the query!")
 	nil))))
 
+(defun notmuch-show--build-queries ()
+  "Return a list of queries to try for this search.
+
+If `notmuch-show-query-context` is not nil, the first query is
+the conjunction of it and `notmuch-show-thread-id`.  The next
+query is `notmuch-show-thread-id` alone, and serves as a fallback
+if the prior matches no messages."
+  (let* ((thread notmuch-show-thread-id)
+	 (context notmuch-show-query-context)
+	 queries)
+    (push (list thread) queries)
+    (if context (push (list thread "and (" context ")") queries))
+    queries))
+
 (defun notmuch-show--build-buffer (&optional state)
   "Display messages matching the current buffer context.
 
@@ -1268,25 +1282,19 @@ Apply the previously saved STATE if supplied, otherwise show the
 first relevant message.
 
 If no messages match the query return NIL."
-  (let* ((basic-args (list notmuch-show-thread-id))
-	 (args (if notmuch-show-query-context
-		   (append (list "\'") basic-args
-			   (list "and (" notmuch-show-query-context ")\'"))
-		 (append (list "\'") basic-args (list "\'"))))
-	 (cli-args (cons "--exclude=false"
+  (let* ((cli-args (cons "--exclude=false"
 			 (when notmuch-show-elide-non-matching-messages
 			   (list "--entire-thread=false"))))
-
-	 (forest (or (notmuch-query-get-threads (append cli-args args))
-		     ;; If a query context reduced the number of
-		     ;; results to zero, try again without it.
-		     (and notmuch-show-query-context
-			  (notmuch-query-get-threads (append cli-args basic-args)))))
-
+	 (queries (notmuch-show--build-queries))
+	 (forest nil)
 	 ;; Must be reset every time we are going to start inserting
 	 ;; messages into the buffer.
 	 (notmuch-show-previous-subject ""))
-
+    ;; Use results from the first query that returns some.
+    (while (and (not forest) (consp queries))
+      (setq forest (notmuch-query-get-threads
+		    (append cli-args (list "'") (car queries) (list "'"))))
+      (setq queries (cdr queries)))
     (when forest
       (notmuch-show-insert-forest forest)
 
-- 
2.8.0.rc3.226.g39d4020

Re:

[Matt Armstrong]

Matt Armstrong <marmstrong@google.com> writes:

> This supercedes
> id:1476207707-21827-1-git-send-email-marmstrong@google.com with
> changes steming from Mark's helpful feedback.

Apologies for the lack of a subject here.  I'm still learning the ins
and outs of 'git send-email'.  I can't say I'd call it a friendly
facility.  :)

Re: [PATCH v3] Add notmuch-show--build-queries.

[Mark Walters]

On Thu, 13 Oct 2016, Matt Armstrong <marmstrong@google.com> wrote:
> notmuch-show--build-buffer now queries a list of queries built by the
> former.  This simplifies the logic.  It also provides an easy place to
> experiment with alternate sets of queries for given notmuch-show-*
> variables (e.g. users can use advice-add to do so in a surgical way).

This is looking pretty good. I suggest a couple of further changes below.
> ---
>  emacs/notmuch-show.el | 36 ++++++++++++++++++++++--------------
>  1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index f2487ab..b393c11 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -1261,6 +1261,20 @@ matched."
>  	(message "No messages matched the query!")
>  	nil))))
>  
> +(defun notmuch-show--build-queries ()
> +  "Return a list of queries to try for this search.
> +
> +If `notmuch-show-query-context` is not nil, the first query is
> +the conjunction of it and `notmuch-show-thread-id`.  The next
> +query is `notmuch-show-thread-id` alone, and serves as a fallback
> +if the prior matches no messages."
> +  (let* ((thread notmuch-show-thread-id)
> +	 (context notmuch-show-query-context)
> +	 queries)
> +    (push (list thread) queries)
> +    (if context (push (list thread "and (" context ")") queries))
> +    queries))
> +

We may want to call this from tree-mode later, so I wonder whether
passing it notmuch-show-thread-id and notmuch-show-query-context as
arguments would make sense. I quite like the idea of this function being
self contained (ie not referencing global state variables). My instinct
is that referencing truly global variables like customise variables is
fine, but I am less keen on referencing buffer-local global variables.

However, some of this depends on what your later plans are.


>  (defun notmuch-show--build-buffer (&optional state)
>    "Display messages matching the current buffer context.
>  
> @@ -1268,25 +1282,19 @@ Apply the previously saved STATE if supplied, otherwise show the
>  first relevant message.
>  
>  If no messages match the query return NIL."
> -  (let* ((basic-args (list notmuch-show-thread-id))
> -	 (args (if notmuch-show-query-context
> -		   (append (list "\'") basic-args
> -			   (list "and (" notmuch-show-query-context ")\'"))
> -		 (append (list "\'") basic-args (list "\'"))))
> -	 (cli-args (cons "--exclude=false"
> +  (let* ((cli-args (cons "--exclude=false"
>  			 (when notmuch-show-elide-non-matching-messages
>  			   (list "--entire-thread=false"))))
> -
> -	 (forest (or (notmuch-query-get-threads (append cli-args args))
> -		     ;; If a query context reduced the number of
> -		     ;; results to zero, try again without it.
> -		     (and notmuch-show-query-context
> -			  (notmuch-query-get-threads (append cli-args basic-args)))))
> -
> +	 (queries (notmuch-show--build-queries))
> +	 (forest nil)
>  	 ;; Must be reset every time we are going to start inserting
>  	 ;; messages into the buffer.
>  	 (notmuch-show-previous-subject ""))
> -
> +    ;; Use results from the first query that returns some.
> +    (while (and (not forest) (consp queries))
> +      (setq forest (notmuch-query-get-threads
> +		    (append cli-args (list "'") (car queries) (list "'"))))
> +      (setq queries (cdr queries)))

One small style point: you can replace the (consp queries) test just
with queries: the empty list equals "nil".

Best wishes

Mark


>      (when forest
>        (notmuch-show-insert-forest forest)
>  
> -- 
> 2.8.0.rc3.226.g39d4020
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3] Add notmuch-show--build-queries.

[Matt Armstrong]

Mark Walters <markwalters1009@gmail.com> writes:

>> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el

[...]

>> +(defun notmuch-show--build-queries ()

[...]

> We may want to call this from tree-mode later, so I wonder whether
> passing it notmuch-show-thread-id and notmuch-show-query-context as
> arguments would make sense. I quite like the idea of this function being
> self contained (ie not referencing global state variables). My instinct
> is that referencing truly global variables like customise variables is
> fine, but I am less keen on referencing buffer-local global variables.

Done.

Perhaps a useful rule of thumb is that functions referencing
buffer-local vars should be interactive?  I'm not sure that follows for
all cases, but I certainly agree that global and buffer-local vars
should probably not be referenced gratuitously, and pure functions are
generally good.


> However, some of this depends on what your later plans are.

Calling what I have in mind "plans" may be a stretch.  ;-) I'm not sure
this function is useful for notmuch-tree as written.  At minimum, I
would expect a shared function to have a different name.  But I think
you're right that there is probably opportunity for code sharing,
especially if notmuch grows more complex features with respect to
searching vs. expanding messages in threads.

Look for a v4 of this patch soon.  I appreciate your review so far.