Thanks for maintaining notmuch!

I'm a long-time mutt user, but have been experimenting with the emacs client,
and found the option that returned the whole thread based on your search very
useful. The notmuch-mutt implementation seemed to lack this functionality, and
at least for the near future I'll probably want to stick with mutt.

I found the combination of using notmuch-mutt search FOO, selecting the message
I wanted to see the thread on, and then using notmuch-mutt thread to
reconstruct the thread for a single message didn't match my workflow well.

I've implemented a proof-of-concept patch that seems to do what I want. It
could probably be implemented a little cleaner as options to search or thread,
though I'll leave that to someone who knows their way around perl better.

Essentially, it does exactly what notmuch-mutt search does, but gets a list of
the thread ids of the search terms, and then passes the thread ids to the
search function, which then symlinks all the messages in relevent threads.

diff --git a/contrib/notmuch-mutt/notmuch-mutt b/contrib/notmuch-mutt/notmuch-mutt
index 4969e4b..3396198 100755
--- a/contrib/notmuch-mutt/notmuch-mutt
+++ b/contrib/notmuch-mutt/notmuch-mutt
@@ -94,6 +94,25 @@ sub search_action($$$@) {
     }
 }

+sub thread_search_action($$$@) {
+    my ($interactive, $results_dir, $remove_dups, @params) = @_;
+
+    if (! $interactive) {
+    	my $search_cmd = 'notmuch search --output=threads ' . shell_quote(join(' ', @params));
+	my $query = `$search_cmd`;
+    	chomp($query);
+	search($results_dir, $remove_dups, $query);
+    } else {
+	my $query = prompt("search ('?' for man): ", join(' ', @params));
+    	my $search_cmd = 'notmuch search --output=threads ' . shell_quote("$query");
+	$query = `$search_cmd`;
+    	chomp($query);
+	if ($query ne "") {
+	    search($results_dir, $remove_dups, $query);
+	}
+    }
+}
+
 sub thread_action($$@) {
     my ($results_dir, $remove_dups, @params) = @_;

@@ -151,6 +170,8 @@ sub main() {
 	search_action($interactive, $results_dir, $remove_dups, @params);
     } elsif ($action eq "thread") {
 	thread_action($results_dir, $remove_dups, @params);
+    } elsif ($action eq "thread-search") {
+	thread_search_action($interactive, $results_dir, $remove_dups, @params);
     } elsif ($action eq "tag") {
 	tag_action(@params);
     } else {
@@ -172,6 +193,8 @@ notmuch-mutt - notmuch (of a) helper for Mutt

 =item B<notmuch-mutt> [I<OPTION>]... search [I<SEARCH-TERM>]...

+=item B<notmuch-mutt> [I<OPTION>]... thread-search [I<SEARCH-TERM>]...
+
 =item B<notmuch-mutt> [I<OPTION>]... thread < I<MAIL>

 =item B<notmuch-mutt> [I<OPTION>]... tag [I<TAGS>]... < I<MAIL>


live well,
  vagrant

Hi Vagrant, thank you for this bug report and patch!

I'm not myself a notmuch-emacs user, but I've stumbled upon the exact
problem you're trying to solve here myself (having to ping pong between
F8-search and F9-reconstruction of threads), I just didn't know what the
Emacs interface was doing about this :-)

About your patch:

I've no substantial objections to your patch (only minor nitpicking here
and there, which I could fix myself). What I wonder about is what would
be the best Mutt user interface for this feature, and I could use some
real user (= you :-), or Emacs users explaining how they do that in
their world) feedback about that.  In particular:

- do you want to have both thread-full and thread-less searches
  available from Mutt?

  (my answer here is yes, because I can easily imagine cases in which
  doing thread-full searches only will degenerate in bloated answers

- would you like to have only one search keybinding + the ability to set
  a default about whether THE search is thread-less/full + the ability
  to override it at invocation-time?

  (implementing it won't be entirely trivial because Mutt's macro
  language is kinda limited in this respect, but I can think about
  something)

TIA,
Cheers.

Thanks for taking a look at it.

As an inexperienced notmuch-emacs user, it seems to only do threads, although
the default search returns each thread as a single line:

 Yest. 19:59 [3/3]   Vagrant Cascadian, Debian Bug Tracking System, Stefano Zacchiroli  Bug#755246: notmuch-mutt: search that returns whole threads (debbugs debian inbox sent signed to)

Selecting that line brings up an indented thread of the messages, which I don't
forsee being feasible to emulate in mutt, unless mutt has some tricks I'm
unaware of (and surely it might).

The other threaded tree view is more like mutt's typical threads:

 Yest. 19:59  Vagrant Cascadian     ┬►Bug#755246: notmuch-mutt: search that returns whole threads (debbugs debian inbox sent signed)
 Yest. 20:03  Debian Bug Tracking   ├─►Bug#755246: Acknowledgement (notmuch-mutt: search that returns whole threads) (debbugs debian inbox to)
 Today 10:35  Stefano Zacchiroli    ╰─►Bug#755246: notmuch-mutt: search that returns whole threads (debbugs debian inbox signed to)

Maybe only one of the messages is in your search terms, but it'll display the
whole thread. This is basically what my patch emulates, through relying on
mutt's normal threading support, and just feeding it all the messages in the
thread.

Yes, I think both are independently useful, largely for the reason you
describe.

Given that I already need to remap the keybindings a bit (usually running mutt
in byobu, which grabs most of the function keys), ideally it could be only one
keybinding. It's probably hard to find enough reasonable non-conflicting
default keybindings as it is...

I would like the ability to set the default via a config file, i.e. full thread
search vs. individual message search, but able to override the default when
invoking a particular query on an as-needed basis...

I guess you could abuse the search term query by adding special search terms
such as thread:yes or thread:no to override whatever the default setting is.
A little ugly, especially if notmuch ever implements a "thread:" query type,
but fairly easy to implement.

It would be annoying to be asked both the search term itself as on question,
followed by a second question asking if you want threaded or unthreaded
responses. Figuring out how to avoid that would be nice.


live well,
  vagrant

*nod*
you describe: the risk of clashes with notmuch. But it just occurred to
me that nomtuch upstream is with us here in this thread! :-)

David: what do you think? Is there a safe way to embed such an "option"
into a notmuch search string, in a way that it doesn't get in the way of
notmuch itself? I'm asking for mutt here, but I suspect it might be
useful in the future for other front-ends (e.g. the day that gmail will
see the light and switch to notmuch for searches *g*).

Yeah, agreed, I'd like to stay away from that as well. But I confess
that if neither this, nor the query escape are possible, we'll likely be
out of options to implement on-the-fly override of the default search
setting.

Cheers.

Stefano Zacchiroli <zack@debian.org> writes:

I'm assuming here that you're going to strip whatever pseudosyntax you
use before passing to notmuch, in which case the main thing is to avoid
clashes with notmuch-search-terms(7) (which, e.g. already meantions
thread: :]).

If you can stand the verbosity, then something like

NOTMUCH_MUTT_OPTIONS=threaded  subject:"search that returns whole
threads"

is probably safest.

If you are thinking about a hypothetical notmuch compatible syntax for
options then I suggest taking the discussion to the upstream mailing
list.

d

Yes, that's the idea.  The main design concerns is hence to avoid stuff
that people might legitimately want to put in a regular notmuch query.

In fact, I was hoping in some sort of meta-syntax, to piggyback on. For
instance, if "field:value" is something that is always threated
specially by notmuch, we can use something like "notmuch:threads" (vs,
say, "notmuch:nothreads") and strip it before it hits notmuch.

If you've no objection to this, I can implement something like it.

Cheers.

Stefano Zacchiroli <zack@debian.org> writes:

(bringing in the upstream list, as this is really an upstream design
issue)

Currently any unrecognized field:value will be searched for as a phrase
[1], and is equivalent to "field value", field.value, field-value, among
others.  So as long as notmuch: is not a recognized prefix, your scheme
will not block any searches.

It doesn't seem especially likely that we'll want to use "notmuch:" as a
prefix; of course if you were to choose something with "mutt" in the
name that would be more nearly a sure thing.



[1]: http://xapian.org/docs/queryparser.html