[PATCH 1/2] Add notmuch-search-unthread-thread

[PATCH 1/2] Add notmuch-search-unthread-thread

[Sandra Snan]

I'm in threads with many thousands of emails. So with this new
`notmuch-search-unthread-thread`, I can be in my normal daily
notmuch-search of tag:inbox and tag:personal and if I put my cursor on
at rhead and then run this command, I get a buffer with the messages
from that thread in a flat list. (Because so huge are the threads that
`notmuch-tree-from-search-thread` can't handle them either.)

And then from that "exploded view" of a thread I can go to messages
one at a time in a non-borking way and then hit q to go back to the
exploded view.
---
 emacs/notmuch.el | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 6eef4af1..c8f53625 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -547,6 +547,23 @@ Return non-nil on success."
       (message "End of search results.")
       nil)))
 
+(defun notmuch-search-unthread-thread (&optional entire)
+  "View the relevant parts of the currently selected thread
+as single messages.
+
+Without a prefix, it only shows the messages from the thread that
+match the search query. With a prefix, it shows the entire
+thread.
+
+Return non-nil on success."
+  (interactive "P")
+  (let ((thread-id (notmuch-search-find-thread-id)))
+    (if thread-id
+	(notmuch-unthreaded (if entire thread-id
+			      (concat notmuch-search-query-string " and " thread-id)))
+      (message "No such thread with that id found!")
+      nil)))
+
 (defun notmuch-tree-from-search-current-query ()
   "Tree view of current query."
   (interactive)
-- 
2.39.2

[PATCH 2/2] Add notmuch-search-show-or-unthread

[Sandra Snan]

This is a dispatch function from the search view that if a thread is
small, it shows it with `notmuch-search-show-thread`, and if it's big,
it shows it with `notmuch-search-show-or-unthread`.

On my own machine I've bound it to `RET` and to `<mouse-1>` in the
notmuch-search-mode-map, but that binding isn't part of this patch.

It shells out to notmuch count to see if the thread is big or small.
"Big" is hardcoded to ten messages or lower, if we want to introduce a
variable for that instead, that might be great.

It's a deliberate choice to count all the messages in the thread, not
just ones that are part of the search (a.k.a. the ones that will show
up in the unthreaded view if the thread is big). The reason for that
is that that's the number that matters when it comes to how well
`notmuch-search-show-thread` can handle it. That's by design. So if
there's a thread with 100000 messages and four of them show up in the
search (maybe because they have a particular tag or date), it'll see
that the thread is big and "explode" it and then show those four new
messages in a flat view.
---
 emacs/notmuch.el | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index c8f53625..e348f660 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -564,6 +564,19 @@ Return non-nil on success."
       (message "No such thread with that id found!")
       nil)))
 
+(defun notmuch-search-show-or-unthread ()
+  "If the thread is small, show it the normal notmuch way, and if
+it's big, show the messages separatley in a buffer so you can
+visit them individually."
+  (interactive)
+  (let ((thread-id (notmuch-search-find-thread-id)))
+    (if thread-id
+	(if (< 11 (notmuch-call-notmuch-sexp "count" thread-id))
+	    (notmuch-search-unthread-thread)
+	    (notmuch-search-show-thread))
+      (message "No such thread with that id found!")
+      nil)))
+
 (defun notmuch-tree-from-search-current-query ()
   "Tree view of current query."
   (interactive)
-- 
2.39.2

Re: [PATCH 2/2] Add notmuch-search-show-or-unthread

[David Bremner]

Sandra Snan <sandra.snan@idiomdrottning.org> writes:
>
> It shells out to notmuch count to see if the thread is big or small.
> "Big" is hardcoded to ten messages or lower, if we want to introduce a
> variable for that instead, that might be great.

Yes, I think a defcustom is called for.

>
> It's a deliberate choice to count all the messages in the thread, not
> just ones that are part of the search (a.k.a. the ones that will show
> up in the unthreaded view if the thread is big). The reason for that
> is that that's the number that matters when it comes to how well
> `notmuch-search-show-thread` can handle it. That's by design. So if
> there's a thread with 100000 messages and four of them show up in the
> search (maybe because they have a particular tag or date), it'll see
> that the thread is big and "explode" it and then show those four new
> messages in a flat view.

Some of that explanation can maybe go in the docstring of the newly
defined customize variable
>  
> +(defun notmuch-search-show-or-unthread ()
> +  "If the thread is small, show it the normal notmuch way, and if
> +it's big, show the messages separatley in a buffer so you can
> +visit them individually."
> +  (interactive)
> +  (let ((thread-id (notmuch-search-find-thread-id)))
> +    (if thread-id
> +	(if (< 11 (notmuch-call-notmuch-sexp "count" thread-id))
> +	    (notmuch-search-unthread-thread)
> +	    (notmuch-search-show-thread))
emacs wants to indent this line differently, so please follow its lead here.

> +      (message "No such thread with that id found!")
> +      nil)))

I guess we should think about a default binding for this. One option is
to replace the default notmuch-search-show-thread binding, and just set
the threshhold very high so that most users will not notice the
change. There is a slight performance penalty from add notmuch count;
I'm not sure if this is noticable. 

Re: [PATCH 2/2] Add notmuch-search-show-or-unthread

[Sandra Snan]

David Bremner <david@tethera.net> writes:
> 1) can you make a test (probably something in T465 can serve as 
> a model

What does T465 refer to?

> 2) Should this be bound by default, or is the function in the 
> next patch always the one users will want?

The latter since it prevents crashes. I've been dogfooding this 
since I made it. It's been so great since I have huge threads 
that used to overload Emacs and that's finally no longer a 
problem.

>> "Big" is hardcoded to ten messages or lower, if we want to 
>> introduce a variable for that instead, that might be great.
>
> Yes, I think a defcustom is called for.

Right. Even if we find the perfect number and set that as the 
default, it's just good Emacs practice to make it a defcustom.

> Some of that explanation can maybe go in the docstring of the 
> newly defined customize variable

I'll try!

> emacs wants to indent this line differently, so please follow 
> its lead here.

Wilco!

> One option is to replace the default notmuch-search-show-thread 
> binding

Yes, that's what I've done locally. An even stronger step in that 
direction would be to make this the new 
notmuch-search-show-thread.

> and just set the threshhold very high so that most users will 
> not notice the change.

But if the treshhold is too big it won't prevent any crashes, 
overloads, or uncomfortably unergonomic thread view. It needs to 
be within a useful range. Maybe 35, 40 or so. I've been sticking 
with the "< 11" threshold I sent in the patch.

> There is a slight performance penalty from add notmuch count; 
> I'm not sure if this is noticable.

Right. Since my machine is very fast I've not noticed any 
slowdown at all. It's instant. A drawback of working on a fast 
machine, I don't know what's too slow for more retro-minded 
users. But even though my machine is fast it still couldn't 
handle the big threads. 

Re: [PATCH 2/2] Add notmuch-search-show-or-unthread

[David Bremner]

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> David Bremner <david@tethera.net> writes:
>> 1) can you make a test (probably something in T465 can serve as 
>> a model
>
> What does T465 refer to?

test/T465-emacs-unthreaded.sh

>
> But if the treshhold is too big it won't prevent any crashes, 
> overloads, or uncomfortably unergonomic thread view. It needs to 
> be within a useful range. Maybe 35, 40 or so. I've been sticking 
> with the "< 11" threshold I sent in the patch.
>
I suggested a large value to make it "opt in", but if there is a broader
consensus I'm fine with a more "active" default.

>> There is a slight performance penalty from add notmuch count; 
>> I'm not sure if this is noticable.
>
> Right. Since my machine is very fast I've not noticed any 
> slowdown at all.

Let's get the function into master and documented and go from
their. Hopefully a few users will give us feedback on performance impact
(if any).

You can preview the documentation with e.g.

   make sphinx-html && firefox _build/html/notmuch-emacs.html

The docs in doc/notmuch-emacs.rst are sortof "semi-automated"; in
cheerful violation of Emacs documentation standards they use the
function docstrings in the manual.

At least the customize can be added, and if it makes sense with our
current level of indecision, the function could be added also (although
the docs are user focused, so they mainly talk about keybindings).

Re: [PATCH 1/2] Add notmuch-search-unthread-thread

[David Bremner]

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> +  (interactive "P")
> +  (let ((thread-id (notmuch-search-find-thread-id)))
> +    (if thread-id
> +	(notmuch-unthreaded (if entire thread-id
> +			      (concat notmuch-search-query-string " and " thread-id)))
> +      (message "No such thread with that id found!")
> +      nil)))
> +

Hi Sandra;

This seems reasonable enough. Two questions

1) can you make a test (probably something in T465 can serve as a model

2) Should this be bound by default, or is the function in the next patch
always the one users will want?