[PATCH] Customize saved search order separately from regular search order

[PATCH] Customize saved search order separately from regular search order

[Keith Packard]

I use 'saved searches' as a folder mechanism and want them to be shown
oldest first. Otherwise, while searching for messages normally, I want
to see the most recent messages first. This patch makes these two
default search orders separate.

Signed-off-by: Keith Packard <keithp@keithp.com>
---
 emacs/notmuch-hello.el |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 6a1c56e..f44b1d3 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -37,6 +37,11 @@
   :type 'integer
   :group 'notmuch)
 
+(defcustom notmuch-saved-search-oldest-first t
+  "Whether saved searches should be oldest first."
+  :type 'boolean
+  :group 'notmuch)
+
 (defcustom notmuch-show-empty-saved-searches nil
   "Should saved searches with no messages be listed?"
   :type 'boolean
@@ -140,7 +145,7 @@ diagonal."
 (defun notmuch-hello-widget-search (widget &rest ignore)
   (notmuch-search (widget-get widget
 			      :notmuch-search-terms)
-		  notmuch-search-oldest-first
+		  notmuch-saved-search-oldest-first
 		  nil nil #'notmuch-hello-search-continuation))
 
 (defun notmuch-saved-search-count (search)
-- 
1.7.0.4

Re: [PATCH] Customize saved search order separately from regular search order

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

On Mon,  3 May 2010 13:58:27 -0700, Keith Packard <keithp@keithp.com> wrote:
> I use 'saved searches' as a folder mechanism and want them to be shown
> oldest first. Otherwise, while searching for messages normally, I want
> to see the most recent messages first. This patch makes these two
> default search orders separate.

This is a nice patch.

dme.
-- 
David Edmondson, http://dme.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Customize saved search order separately from regular search order

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]

On Tue, 04 May 2010 12:02:22 +0100, David Edmondson <dme@dme.org> wrote:
> On Mon,  3 May 2010 13:58:27 -0700, Keith Packard <keithp@keithp.com> wrote:
> > I use 'saved searches' as a folder mechanism and want them to be shown
> > oldest first. Otherwise, while searching for messages normally, I want
> > to see the most recent messages first. This patch makes these two
> > default search orders separate.
> 
> This is a nice patch.

I think this is a nice start, but that we actually want a different
notion here.

Keith happens to use saved searches only for subsets of his inbox and in
that case, it makes a lot of sense to see the results of all of these
messages in an oldest-first order.

But saved searches are also useful for simply capturing what might be an
often-used but otherwise painful-to-keep-retyping search expression
where the user really wants the results to appear with the newest
message first, (which is the default search-results order after all).

So I think what we actually want here is an additional member for our
saved-search tuple which indicates the desired search order for that
particular search. That's the only way I see to support a single user
who wants to take advantage of both kinds of searches.

Thoughts?

A separated, but perhaps related idea would be to explicitly support the
notion of one search being a subset of another. I have an "inbox" search
(tag:inbox) and several searches that are subsets, ("notmuch" is
"tag:notmuch and tag:inbox"). If this were setup as an actual hierarchy
it might have two advantages:

	1. It would be a bit simpler to specify all of theses searches,
	   I wouldn't have to keep repeating "and tag:inbox" in each.
	   This would be particularly important if I changed the
	   criteria for the top-level search.

	2. If the various levels of the hierarchy were displayed
	   separately it would be easier for me to focus on processing
	   all of my inbox folders (which happen to be
	   oldest-first)--archiving each down to 0 messages, without
	   being distracted by several (newest-first) saved searches
	   that will only ever grow and don't have any
	   processing/archiving associated with them.

I think that currently I'm not using any of these
always-growing/newest-first searches in part because they would be mixed
up with my inbox-subset folders and would thereby be distracting. So (2)
above would allow me to start using them, and then I would want the
feature to selectively set the search order.

-Carl

-- 
carl.d.worth@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Customize saved search order separately from regular search order

[Michal Sojka]

On Fri, 04 Jun 2010, Carl Worth wrote:
> Keith happens to use saved searches only for subsets of his inbox and in
> that case, it makes a lot of sense to see the results of all of these
> messages in an oldest-first order.

Hi,

I used saved searches mostly this way until a few days ago, when I wrote
"What's in your inbox" patch (I'll send it as a reply to this mail). I
have to say I'm quite satisfied with it.

-Michal

[PATCH RFC] notmuch-hello: What's in your inbox

[Michal Sojka]

Hello,

I found myself very often adding something like 'tag:inbox and ...' to
the saved searches. I want my messages to be tagged by mailing list so
whenever I subscribe to a new mailing list I have to update both the
tagging script and saved searches. This work duplication doesn't seem
ideal for me so here is a patch, which shows a section "What's in your
inbox" in notmuch-hello screen. This section contains all tags of
messages that are tagged by "inbox".

It would be nice to have some configuration for the "What's in your
inbox" section - for example to specify which tags are not interesting
for me (e.g. unread).

I'm not sure whether the patch applies to recent dme's notmuch-hello
updates. If not, I'll rebase it as soon as these patches appear in
master.

Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>

---
 emacs/notmuch-hello.el |   39 +++++++++++++++++++++++++++++++++++++--
 1 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 6a1c56e..e61f37a 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -55,6 +55,11 @@
   :type 'boolean
   :group 'notmuch)
 
+(defcustom notmuch-show-inbox-tags-list nil
+  "Should all tags in your inbox be shown in the notmuch-hello view?"
+  :type 'boolean
+  :group 'notmuch)
+
 (defface notmuch-hello-logo-background
   '((((class color)
       (background dark))
@@ -289,7 +294,36 @@ diagonal."
 				(mapcar '(lambda (tag) (cons tag (concat "tag:" tag)))
 					(process-lines notmuch-command "search-tags"))))
 	     (alltags-widest (notmuch-hello-longest-label alltags-alist))
-	     (widest (max saved-widest alltags-widest)))
+	     (inboxtags-alist (if notmuch-show-inbox-tags-list
+				  (mapcar '(lambda (tag) (cons tag (concat "tag:inbox and tag:" tag)))
+					  (process-lines notmuch-command "search-tags" "tag:inbox"))))
+	     (inboxtags-widest (notmuch-hello-longest-label inboxtags-alist))
+	     (widest (max saved-widest alltags-widest inboxtags-widest)))
+
+
+	(when inboxtags-alist
+	  (widget-insert "What's in your inbox: ")
+	  (widget-create 'push-button
+			 :notify (lambda (widget &rest ignore)
+				   (setq notmuch-show-inbox-tags-list nil)
+				   (notmuch-hello-update))
+			 "hide")
+	  (widget-insert "\n\n")
+	  (setq final-target-pos (point-marker))
+	  (let ((start (point)))
+	    (setq found-target-pos (notmuch-hello-insert-tags inboxtags-alist widest target))
+	    (if (not final-target-pos)
+		(setq final-target-pos found-target-pos))
+	    (indent-rigidly start (point) notmuch-hello-indent)))
+
+	(when (not notmuch-show-inbox-tags-list)
+	  (widget-create 'push-button
+			 :notify (lambda (widget &rest ignore)
+				   (setq notmuch-show-inbox-tags-list t)
+				   (notmuch-hello-update))
+			 "Show tags in your inbox")
+	  (widget-insert "\n"))
+	(widget-insert "\n")
 
 	(when saved-alist
 	  (widget-insert "Saved searches: ")
@@ -297,8 +331,9 @@ diagonal."
 			 :notify (lambda (&rest ignore)
 				   (customize-variable 'notmuch-saved-searches))
 			 "edit")
+	  (if (not final-target-pos)
+	      (setq final-target-pos (point-marker)))
 	  (widget-insert "\n\n")
-	  (setq final-target-pos (point-marker))
 	  (let ((start (point)))
 	    (setq found-target-pos (notmuch-hello-insert-tags saved-alist widest target))
 	    (if found-target-pos
-- 
tg: (1d528f8..) t/emacs-what-is-in-your-inbox (depends on: master)

Re: [PATCH] Customize saved search order separately from regular search order

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

On Thu, 03 Jun 2010 17:45:20 -0700, Carl Worth <cworth@cworth.org> wrote:
> So I think what we actually want here is an additional member for our
> saved-search tuple which indicates the desired search order for that
> particular search. That's the only way I see to support a single user
> who wants to take advantage of both kinds of searches.

That seems straightforward to implement in the code and only slightly
complicated in the customisation interface (though I haven't done it
yet).

> A separated, but perhaps related idea would be to explicitly support the
> notion of one search being a subset of another. I have an "inbox" search
> (tag:inbox) and several searches that are subsets, ("notmuch" is
> "tag:notmuch and tag:inbox"). If this were setup as an actual hierarchy
> it might have two advantages:
> 
> 	1. It would be a bit simpler to specify all of theses searches,
> 	   I wouldn't have to keep repeating "and tag:inbox" in each.
> 	   This would be particularly important if I changed the
> 	   criteria for the top-level search.
> 
> 	2. If the various levels of the hierarchy were displayed
> 	   separately it would be easier for me to focus on processing
> 	   all of my inbox folders (which happen to be
> 	   oldest-first)--archiving each down to 0 messages, without
> 	   being distracted by several (newest-first) saved searches
> 	   that will only ever grow and don't have any
> 	   processing/archiving associated with them.

Writing code to manipulate and use a structure like this would obviously
be some effort, but it doesn't seem overly difficult. More challenging
would be the interface to allow the user to customise the structure to
express their intentions. Do you have any thoughts on that?

dme.
-- 
David Edmondson, http://dme.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Customize saved search order separately from regular search order

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On Mon, 07 Jun 2010 14:49:23 +0100, David Edmondson <dme@dme.org> wrote:
> Writing code to manipulate and use a structure like this would obviously
> be some effort, but it doesn't seem overly difficult. More challenging
> would be the interface to allow the user to customise the structure to
> express their intentions. Do you have any thoughts on that?

Moreover, what happens if the user types in a search by hand and then
wishes to make it a saved search? Determining the best/right way to
insert it into the considerably more complex `notmuch-saved-searches'
structure sounds hard.

If this data structure were only ever manipulated by editing .emacs then
I'd have no problem. Currently that's not the case.

dme.
-- 
David Edmondson, http://dme.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]