Re: [PATCH] Added --initial-index and --last-index to search/show
On Sat, 20 Aug 2011 12:21:26 +0100, Patrick Totzke patricktot...@googlemail.com wrote: Non-text part: multipart/mixed Hi! A very good idea indeed! This could become quite handy speeding up my interface. One question: What do you (intend to) do to ensure that accumulated results 'add up well'? I intend to do nothing. It's up to the interface to handle this, if it needs handling at all. Consider the following: you query some 10 threads, the user tags one of them so that it doesn't macht anymore and afterwards you list the next 100 threads. After the tagging, the number of hits decreases, so if you query from hit number 101 to 200, you will not return the 100th (now 99th) thread at all. The interface could keep track of threads deleted/untagged and adjust accordingly. Or I suppose one could also implement --initial-msgid, --last-msgid, --num-threads, etc. Set --initial-msgid to the last message in your current view. Set --num-threads to 100. That should do it. Ok, one could always list all threads up to the one one is interested in but that would make refreshing the list slower and slower when you keep scrolling down.. Personally, I think users should be discouraged from scrolling and scrolling. Notmuch is a *search* tool. If the mail you want isn't in the first page or so, you're using the tool wrong. -J ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Return maximum of 150 results
On Fri, 19 Aug 2011 17:00:23 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: If you really want this behavior, I propose to make the default value of notmuch-max-results infinity. I'm attaching a revised patch that does as you suggest. Thanks. From d0421e4308473347b31f5537eaec93b137084060 Mon Sep 17 00:00:00 2001 From: James Vasile ja...@hackervisions.org Date: Sat, 20 Aug 2011 14:58:47 -0400 Subject: [PATCH] Limit number of threads returned by search in emacs Set notmuch-max-results to the maximum number of results the client should show. Setting notmuch-max-results to 0 (the default) does not limit search results (i.e. limits them to infinity). This patch requries your version of notmuch to implement the --last-index parameter. A patch to implement this parameter was posted to the notmuch mailing list as id:8739gyw0zh@opensourcematters.org. --- emacs/notmuch.el |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index f11ec24..887d696 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -882,6 +882,7 @@ characters as well as `_.+-'. (concat *notmuch-search- query *)) ))) +(defvar notmuch-max-results 0) ;;;###autoload (defun notmuch-search (query optional oldest-first target-thread target-line continuation) Run \notmuch search\ with the given query string and display results. @@ -913,6 +914,9 @@ The optional parameters are used as follows: (let ((proc (start-process notmuch-search buffer notmuch-command search + (if ( notmuch-max-results 0) + (format --last-index=%d notmuch-max-results) + ) (if oldest-first --sort=oldest-first --sort=newest-first) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Added --initial-index and --last-index to search/show
Hi! A very good idea indeed! This could become quite handy speeding up my interface. One question: What do you (intend to) do to ensure that accumulated results 'add up well'? Consider the following: you query some 10 threads, the user tags one of them so that it doesn't macht anymore and afterwards you list the next 100 threads. After the tagging, the number of hits decreases, so if you query from hit number 101 to 200, you will not return the 100th (now 99th) thread at all. Ok, one could always list all threads up to the one one is interested in but that would make refreshing the list slower and slower when you keep scrolling down.. best, /p
[PATCH] Added --initial-index and --last-index to search/show
On Sat, 20 Aug 2011 12:21:26 +0100, Patrick Totzke wrote: Non-text part: multipart/mixed > > > Hi! > A very good idea indeed! This could become quite handy speeding up my > interface. > One question: What do you (intend to) do to ensure that accumulated results > 'add up well'? I intend to do nothing. It's up to the interface to handle this, if it needs handling at all. > Consider the following: you query some 10 threads, the user tags one of them > so that it doesn't macht anymore and afterwards you list the next 100 threads. > After the tagging, the number of hits decreases, so if you query > from hit number 101 to 200, you will not return the 100th (now 99th) > thread at all. The interface could keep track of threads deleted/untagged and adjust accordingly. Or I suppose one could also implement --initial-msgid, --last-msgid, --num-threads, etc. Set --initial-msgid to the last message in your current view. Set --num-threads to 100. That should do it. > > Ok, one could always list all threads up to the one one is interested in but > that > would make refreshing the list slower and slower when you keep > scrolling down.. Personally, I think users should be discouraged from scrolling and scrolling. Notmuch is a *search* tool. If the mail you want isn't in the first page or so, you're using the tool wrong. -J
[PATCH] Return maximum of 150 results
On Fri, 19 Aug 2011 17:00:23 +0200, Michal Sojka wrote: > If you really want this behavior, I propose to make the default value > of notmuch-max-results infinity. I'm attaching a revised patch that does as you suggest. Thanks. -- next part -- A non-text attachment was scrubbed... Name: 0001-Limit-number-of-threads-returned-by-search-in-emacs.patch Type: text/x-diff Size: 1509 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110820/282f0d2c/attachment.patch>
