[PATCH 2/2] [RFC] possible solution for "Race condition for '*' command"

2011-06-30 Thread Pieter Praet 
On Thu, 30 Jun 2011 18:08:28 +0200, Pieter Praet  wrote:
> `notmuch-search-operate-all' may cause a race condition because
> repeatedly running `notmuch-tag' with the *original* query string
> makes the result list a moving target.
> 
> One approach to resolving this, is to feed `notmuch-tag' a static result
> list based on the original query string, instead of the latter itself.
> 
> See discussion @ id:"86d3i1d06r.fsf at dragonfly.greenrd.org"
> 
> Signed-off-by: Pieter Praet 
> ---
> 
> Carl,
> 
> I've gone along a different route which assures only matched messages
> are touched, but it does come with quite a performance hit.
> 
> Since there isn't a test for the actual race condition(s), I can't be
> sure, but theoretically, at least one of them should be fixed now.
> 
> Peace
> 
>  emacs/notmuch.el |   11 +--
>  1 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index f11ec24..84c3ee6 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -845,7 +845,8 @@ Each character of the tag name may consist of alphanumeric
>  characters as well as `_.+-'.
>  "
>(interactive "sOperation (+add -drop): notmuch tag ")
> -  (let ((action-split (split-string action " +")))
> +  (let ((action-split (split-string action " +"))
> +(query notmuch-search-query-string))
>  ;; Perform some validation
>  (let ((words action-split))
>(when (null words) (error "No operation given"))
> @@ -853,7 +854,13 @@ characters as well as `_.+-'.
>   (unless (string-match-p "^[-+][-+_.[:word:]]+$" (car words))
> (error "Action must be of the form `+thistag -that_tag'"))
>   (setq words (cdr words
> -(apply 'notmuch-tag notmuch-search-query-string action-split)))
> +(dolist (msgid
> +(split-string
> +  (with-output-to-string
> +(with-current-buffer standard-output
> +  (apply 'call-process notmuch-command nil t nil "search" 
> "--output=messages" (list query
> +"\n+" t))
> +(apply 'notmuch-tag msgid action-split
>  
>  (defun notmuch-search-buffer-title (query)
>"Returns the title for a buffer with notmuch search results."
> -- 
> 1.7.4.1
> 

Ok, even though my very first reply [1] may have created the impression
that I understood the issue, I clearly didn't...

The test [2] needs a more applicable commit message, and the subsequent
patch [3] points more or less in the right direction, but the Message-Id
list should be local to the *search buffer* rather than to the
`notmuch-search-operate-all' function.

`notmuch-search' could:
  - run "notmuch-command search" with the "--output=messages" option
instead of a plain search,
  - maintain a buffer-local var with a list of returned Message-Id's,
  - ...and populate the buffer based on that list.

As such we'd have -for each individual search buffer- a canonical list
of Message-Id's (i.e. messages which actually *match* the query AND are
currently visible in the search buffer), to be used by
`notmuch-search-operate-all' et al.


Peace

-- 
Pieter

[1] id:"87fwmuxxgd.fsf at praet.org"
[2] id:"1309450108-2793-2-git-send-email-pieter at praet.org"
[3] id:"1309450108-2793-1-git-send-email-pieter at praet.org"

[PATCH] remove prefixes from `--output={threads, messages}' results

2011-06-30 Thread Pieter Praet 
On Thu, 30 Jun 2011 09:24:12 -0700, Carl Worth  wrote:
Non-text part: multipart/signed
> On Thu, 30 Jun 2011 10:19:49 +0200, Pieter Praet  wrote:
> > Alter `do_search_threads()' and `do_search_messages()'
> > to not prepend each result with `thread:' respectively `id:'.
> 
> My one concern here is that I've sometimes had a message-id without the
> id prefix and run a command like this:
> 
> notmuch search 1309421989-22410-1-git-send-email-pieter at praet.org
> 
> And I've gotten confused when I've received no output, (didn't I receive
> that mail? what happened?).

And unfortunately, that's not the only concern.

While this patch removes a mere 10 chars, it has (way too) far-reaching
consequences, not only for the test suite, but for the entire codebase.

Truth be told, this was never intended to be merged. I only sent this
patch to give a ~fair chance to what appears to be the general
consensus, but I much prefer the fix for do_search_tags() [1].

In fact, all the followup patches (the seemingly haphazard reply nesting
is intentional) are intended to be used with the do_search_tags() fix,
which I tentatively consider a much cleaner path.

> But I think this is a separate bug where the right fix is to make any
> search terms with no prefix search through *all* prefixed terms
> generated from email content. This would allow us to also avoid indexing
> some content twice, (currently we store subject, from, and to both with
> a prefix and without a prefix).

Indeed a most desirable (albeit perhaps long-term) goal.

Much as I'd like, I won't be able to make myself useful in that area for
the time being, as the only C I consider myself sufficiently capable of
pushing around is the one ending with "offee" :<

> -Carl
> 
> -- 
> carl.d.worth at intel.com
Non-text part: application/pgp-signature

Peace

-- 
Pieter

[1] id:"1309422029-22924-1-git-send-email-pieter at praet.org"

[PATCH 1/2] test: add/remove tags from all matching messages with `notmuch-search-operate-all'

2011-06-30 Thread Pieter Praet 
This test is meant solely to make sure my next patch
doesn't break anything (in an obvious way, at least).

In other words: it does *not* demonstrate a race condition issue.

Signed-off-by: Pieter Praet 
---

Robin,

Could you provide a test to expose the actual race condition?
Or at the very least something to mitigate my severe clue-deficiency?

Peace

 test/emacs |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/test/emacs b/test/emacs
index 53f455a..ffe8a55 100755
--- a/test/emacs
+++ b/test/emacs
@@ -347,4 +347,23 @@ test_emacs '(notmuch-show 
"id:f35dbb950911171438k5df6eb56k77b6c0944e2e79ae at mail.
(test-visible-output)'
 test_expect_equal_file OUTPUT 
$EXPECTED/notmuch-show-thread-with-hidden-messages

+test_begin_subtest "Add/remove tags from all matching messages."
+test_emacs '(notmuch-search "tag:inbox AND tags")
+   (notmuch-test-wait)
+   (notmuch-search-operate-all "+matching -inbox")
+   (notmuch-search "tag:matching")
+   (notmuch-test-wait)
+   (test-output)'
+cat

Preventing the user shooting themself in the foot

2011-06-30 Thread Brian May 
On 30 June 2011 08:40, Carl Worth  wrote:
> The 'a' keybinding, (in turn), was designed for cases when you *know*
> you don't want to read the rest of the thread.

... in which case it should also mark everything as read. IMHO.

Are there any keyboard bindings to go forwards to the next message or
backwards to the last message without marking anything as archived?

Also, just something I have noticed it isn't really obvious that a
thread has replies without scrolling down, and that takes time. Would
be really good if there could be some big/highlighted visual indicator
that there are still unread messages further down.
-- 
Brian May

patchwork

2011-06-30 Thread martin f krafft 
Are people using http://patchwork.notmuchmail.org at all? The reason
of my asking is that it receives quite a lot of spam and I do not
need to invest this time for a service noone uses.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"'oh, that was easy,' says Man, and for an encore goes on to prove
 that black is white and gets himself killed on the next zebra
 crossing."
-- douglas adams, "the hitchhiker's guide to the galaxy"

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see 
http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110630/38bf53e2/attachment.pgp>

Notmuch 0.6: Let's do it.

2011-06-30 Thread David Bremner 

> The release plan is as follows.
> 
> 4) Release July 1.
> 

We are getting close. I have tagged 0.6rc1 in
git://git.notmuchmail.org/git/notmuch and uploaded 0.6~rc1 to Debian
unstable.

Barring fubars, the only changes from here should be documentation [1]

Your friendly release tyrant,

David

[1] And Debian packaging, if you count that.

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110630/6ee7fe10/attachment.pgp>

Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet 
On Thu, 30 Jun 2011 09:50:27 +0200, Pieter Praet  wrote:
> [...]
> And AFAIK, "Archive" does *not* mark a message as read in GMail.
> (see previous messages suggesting the inverse [...]
... be implemented in Notmuch.

> [...] )

Nobody claimed the inverse was the case in GMail, so I created the wrong
impression. I should've picked my words more carefully.


Peace

-- 
Pieter

[PATCH] fix breakage in `notmuch-select-tag-with-completion' due to `tag:' prefix

2011-06-30 Thread Pieter Praet 
Even though all tests passed, a previous patch [1] seems to have broken
`notmuch-select-tag-with-completion', because the latter expects prefix-less 
tags.

This is a quick'n'dirty patch, thus probably not fit for consumption.
But it Works(TM).

[1] id:"1309422029-22924-1-git-send-email-pieter at praet.org"

Signed-off-by: Pieter Praet 
---
 emacs/notmuch.el |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..af66510 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -77,7 +77,11 @@ For example:
 (with-output-to-string
   (with-current-buffer standard-output
 (apply 'call-process notmuch-command nil t nil "search-tags" 
search-terms)
-(completing-read prompt (split-string tag-list "\n+" t) nil nil nil)))
+(completing-read prompt
+(mapcar (lambda (tag)
+  (substring tag 4))
+(split-string tag-list "\n+" t))
+nil nil nil)))

 (defun notmuch-foreach-mime-part (function mm-handle)
   (cond ((stringp (car mm-handle))
-- 
1.7.4.1

[PATCH] fix breakage in `notmuch-hello-generate-tag-alist' due to `tag:' prefix

2011-06-30 Thread Pieter Praet 
Even though all tests passed, a previous patch [1] seems to have broken
`notmuch-hello-generate-tag-alist', because the latter expects prefix-less tags.

This is a quick'n'dirty patch, thus probably not fit for consumption.
But it Works(TM).

[1] id:"1309422029-22924-1-git-send-email-pieter at praet.org"

Signed-off-by: Pieter Praet 
---
 emacs/notmuch-hello.el |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 65fde75..4551be1 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -343,6 +343,7 @@ Complete list of currently available key bindings:
   (notmuch-remove-if-not
#'cdr
(mapcar (lambda (tag)
+(let ((tag (substring tag 4)))
 (cons tag
   (cond
((functionp notmuch-hello-tag-list-make-query)
@@ -351,10 +352,11 @@ Complete list of currently available key bindings:
((stringp notmuch-hello-tag-list-make-query)
 (concat "tag:" tag " and ("
 notmuch-hello-tag-list-make-query ")"))
-   (t (concat "tag:" tag)
+   (t (concat "tag:" tag))
   (notmuch-remove-if-not
(lambda (tag)
- (not (member tag notmuch-hello-hide-tags)))
+ (let ((tag (substring tag 4)))
+ (not (member tag notmuch-hello-hide-tags
(process-lines notmuch-command "search-tags")

 ;;;###autoload
-- 
1.7.4.1

[PATCH] test: stashing in notmuch-{show,search}

2011-06-30 Thread Pieter Praet 
Should provide full test coverage of the stashing feature.

Signed-off-by: Pieter Praet 
---
 test/emacs|   41 +
 test/emacs.expected-output/emacs-stashing |9 ++
 2 files changed, 50 insertions(+), 0 deletions(-)
 create mode 100644 test/emacs.expected-output/emacs-stashing

diff --git a/test/emacs b/test/emacs
index 53f455a..46076c6 100755
--- a/test/emacs
+++ b/test/emacs
@@ -347,4 +347,45 @@ test_emacs '(notmuch-show 
"id:f35dbb950911171438k5df6eb56k77b6c0944e2e79ae at mail.
(test-visible-output)'
 test_expect_equal_file OUTPUT 
$EXPECTED/notmuch-show-thread-with-hidden-messages

+test_begin_subtest "Stashing in notmuch-show"
+add_message '[date]="Sat, 01 Jan 2000 12:00:00 -"' \
+'[from]="Some One "' \
+'[to]="Some One Else "' \
+'[cc]="Notmuch "' \
+'[subject]="Stash my stashables"' \
+'[id]="bought"' \
+'[body]="Unable to stash body. Where did you get it in the first place?!?"'
+notmuch tag +stashtest id:${gen_msg_id}
+test_emacs '(notmuch-show "id:\"bought\"")
+(notmuch-show-stash-date)
+(notmuch-show-stash-from)
+(notmuch-show-stash-to)
+(notmuch-show-stash-cc)
+(notmuch-show-stash-subject)
+(notmuch-show-stash-message-id)
+(notmuch-show-stash-message-id-stripped)
+(notmuch-show-stash-tags)
+(notmuch-show-stash-filename)
+(switch-to-buffer
+  (generate-new-buffer "*test-stashing*"))
+(dotimes (i 9)
+  (yank)
+  (insert "\n")
+  (rotate-yank-pointer 1))
+(reverse-region (point-min) (point-max))
+   (test-output)'
+sed -i -e 's/^.*tmp.emacs\/mail.*$/FILENAME/' OUTPUT
+test_expect_equal_file OUTPUT $EXPECTED/emacs-stashing
+
+test_begin_subtest "Stashing in notmuch-search"
+test_emacs '(notmuch-search "id:\"bought\"")
+(notmuch-test-wait)
+(notmuch-search-stash-thread-id)
+(switch-to-buffer
+  (generate-new-buffer "*test-stashing*"))
+(yank)
+   (test-output)'
+sed -i -e 's/^thread:.*$/thread:XXX/' OUTPUT
+test_expect_equal $(cat OUTPUT) "thread:XXX"
+
 test_done
diff --git a/test/emacs.expected-output/emacs-stashing 
b/test/emacs.expected-output/emacs-stashing
new file mode 100644
index 000..4923594
--- /dev/null
+++ b/test/emacs.expected-output/emacs-stashing
@@ -0,0 +1,9 @@
+Sat, 01 Jan 2000 12:00:00 -
+Some One 
+Some One Else 
+Notmuch 
+Stash my stashables
+id:"bought"
+bought
+inbox,stashtest
+FILENAME
-- 
1.7.4.1

[PATCH] emacs: add keybind and function to stash Message-ID without prefix

2011-06-30 Thread Pieter Praet 
Add function `notmuch-show-stash-message-id-stripped'
which stashes a Message-ID after ripping off the prefix and quotes,
add bind it to "I" key in `notmuch-show-stash-map'.

Simplifying `notmuch-show-get-message-id' instead might seem better,
but that would require concat'ing in 9 places instead of 1.

Signed-off-by: Pieter Praet 
---
 emacs/notmuch-show.el |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 6685717..a703732 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -858,6 +858,7 @@ function is used. "
 (define-key map "F" 'notmuch-show-stash-filename)
 (define-key map "f" 'notmuch-show-stash-from)
 (define-key map "i" 'notmuch-show-stash-message-id)
+(define-key map "I" 'notmuch-show-stash-message-id-stripped)
 (define-key map "s" 'notmuch-show-stash-subject)
 (define-key map "T" 'notmuch-show-stash-tags)
 (define-key map "t" 'notmuch-show-stash-to)
@@ -1408,6 +1409,11 @@ buffer."
   (interactive)
   (notmuch-common-do-stash (notmuch-show-get-message-id)))

+(defun notmuch-show-stash-message-id-stripped ()
+  "Copy message ID of current message (sans `id:' prefix) to kill-ring."
+  (interactive)
+  (notmuch-common-do-stash (substring (notmuch-show-get-message-id) 4 -1)))
+
 (defun notmuch-show-stash-subject ()
   "Copy Subject field of current message to kill-ring."
   (interactive)
-- 
1.7.4.1

[PATCH] remove prefixes from `--output={threads,messages}' results

2011-06-30 Thread Pieter Praet 
Alter `do_search_threads()' and `do_search_messages()'
to not prepend each result with `thread:' respectively `id:'.

This makes its output consistent with `do_search_tags()'.

See this discussion: id:"871v6b79s0.fsf at yoom.home.cworth.org"



NOTE:

I started adjusting the tests as well, but stopped fairly quickly since
the amount is simply *ludicrous*. Only 9 tests fail initially, but start
ripping out `notmuch_search_sanitize' (as would be sensible) and you'll
see what I mean.

Time isn't the issue (sed flies through it faster than Windoze can BSOD),
but the patch will be so huge and disruptive that even Ubuntu devs might
consider frowning disapprovingly.



Signed-off-by: Pieter Praet 
---
 notmuch-search.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/notmuch-search.c b/notmuch-search.c
index faccaf7..c565ae6 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -220,7 +220,7 @@ do_search_threads (const search_format_t *format,
thread = notmuch_threads_get (threads);

if (output == OUTPUT_THREADS) {
-   format->item_id (thread, "thread:",
+   format->item_id (thread, "",
 notmuch_thread_get_thread_id (thread));
} else { /* output == OUTPUT_SUMMARY */
fputs (format->item_start, stdout);
@@ -312,7 +312,7 @@ do_search_messages (const search_format_t *format,
if (! first_message)
fputs (format->item_sep, stdout);

-   format->item_id (message, "id:",
+   format->item_id (message, "",
 notmuch_message_get_message_id (message));
first_message = 0;
}
-- 
1.7.4.1

[PATCH 4/4] emacs: Add pseudo tag to match all messages that have no tags

2011-06-30 Thread Pieter Praet 
On Tue, 28 Jun 2011 07:31:32 +, Jani Nikula  wrote:
> Add a pseudo tag that matches all the messages that have no tags. Add new
> customization option notmuch-tags-nomatch to enable and name the pseudo
> tag.
> ---
>  emacs/notmuch-hello.el |   18 --
>  1 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index b9c9b01..1770f60 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -53,6 +53,12 @@
>string)
>:group 'notmuch)
>  
> +(defcustom notmuch-tags-nomatch nil
> +  "Name of the pseudo tag to match messages that have no tags."
> +  :type '(choice (const :tag "Off" nil)
> +  string)
> +  :group 'notmuch)
> +
>  (defvar notmuch-hello-indent 4
>"How much to indent non-headers.")
>  
> @@ -352,7 +358,7 @@ Complete list of currently available key bindings:
>  
>  (defun notmuch-hello-generate-tag-alist ()
>"Return an alist from tags to queries to display in the all-tags section."
> -  (notmuch-remove-if-not
> +  (let ((tag-alist (notmuch-remove-if-not
> #'cdr
> (mapcar (lambda (tag)
>(cons tag
> @@ -367,7 +373,15 @@ Complete list of currently available key bindings:
>  (notmuch-remove-if-not
>   (lambda (tag)
> (not (member tag notmuch-hello-hide-tags)))
> - (process-lines notmuch-command "search-tags")
> + (process-lines notmuch-command "search-tags"))
> +(when notmuch-tags-nomatch
> +  (let ((no-tag-search
> +  (cons notmuch-tags-nomatch
> +(mapconcat (lambda (arg) (concat "(not (" (cdr arg) "))")) 
> tag-alist " and "
> + (if (> (string-to-number (notmuch-saved-search-count (cdr 
> no-tag-search))) 0)
> + ;; Append the no-match search.
> + (add-to-list 'tag-alist no-tag-search t
> +tag-alist))
>  
>  (defun notmuch-hello-saved-alist ()
>(if notmuch-saved-searches
> -- 
> 1.7.1
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


IMHO, this should be handled in notmuch core.

eg.
  `notmuch search tag:*' matches all tagged
  `notmuch search tag:'  matches all non-tagged.

-> No need for an extra customization option in Emacs,
   just a simple saved search.

Opinions?


Peace

-- 
Pieter

Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet 
On Wed, 29 Jun 2011 19:53:03 -0400, Austin Clements  wrote:
Non-text part: multipart/mixed
Non-text part: multipart/alternative
> I've spent embarrassingly little time in the emacs UI, so my opinions on
> this should be taken lightly, but I feel like all of the bindings are of the
> form "if W, do X and Y, otherwise do Z" and, as a result, I'm actively
> afraid of what's going to happen when I hit a key. I would much prefer
> bindings with simple, highly predictable behavior. I'm sure there's some
> workflow for which these contextual, compound bindings are fantastic, but
> other workflows wind up fighting against them.

Very true!

> I don't have a specific proposal in mind, but Gmail's bindings seem like a
> good model to emulate (the actions, at least; I've never been too fond of
> the specific key choices).

+1

And AFAIK, "Archive" does *not* mark a message as read in GMail.
(see previous messages suggesting the inverse)

> On Jun 29, 2011 6:40 PM, "Carl Worth"  wrote:
Non-text part: text/html
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter

Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet 
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> On Thu, 30 Jun 2011 13:04:23 +1000, Brian May  microcomaustralia.com.au> wrote:
> > On 30 June 2011 08:40, Carl Worth  wrote:
> > > The 'a' keybinding, (in turn), was designed for cases when you *know*
> > > you don't want to read the rest of the thread.
> > 
> > ... in which case it should also mark everything as read. IMHO.
> 
> I know the current behavior only catches my opinion (and only an opinion
> I had at one particular point in time). So I won't say this is Right,
> but I will at least explain what I was thinking:
> 
> The "unread" tag is distinct from the "inbox" tag. Why two tags? Don't
> they normally change at the same time? If a key like 'a' got rid of the
> "unread" tag as well as the "inbox" then there would be almost no need
> for having two tags.
> 
> The idea I had is that "inbox" is fully under explicit control by the
> user. The user must make an intentional decision to "archive" a message
> in order for that tag to be removed.
> 
> Distinct from that is "unread" which is handled automatically by the
> mail client (as well as it can tell what you've actually read or
> not). So this tag is removed only implicitly, (we don't have specific
> commands to manipulate the "unread" tag). When the client displays a
> message as the "current" message it immediately removes the "unread"
> tag.
> 
>  Whenever it displays a message to the
> user, (as the "current" message), it removes the unread tag from that
> message.
> 
> This means that messages can lose the "unread" tag while still remaining
> tagged "inbox", (you read a message, but don't archive it), and that
> messages can lose the "archive" tag while still remaining tagged
> "unread", (you archive a thread before reading all messages in the
> thread).
> 
> The distinction ends up being useful to me. If at some point someone
> points me to a specific message, and when I search for it I see the
> "unread" tag, then this highlights to me that I never even looked at the
> message.
> 
> > Are there any keyboard bindings to go forwards to the next message or
> > backwards to the last message without marking anything as archived?
> 
> As mentioned by someone else, you can navigate the messages in a thread
> with 'n' and 'p'.
> 
> One of the obviously missing keybindings is a way to easily navigate
> From the current thread to the next thread without archiving the current
> thread. We should probably add that keybinding at some point, but I want
> to at least point out why I didn't create it originally:
> 
> The lack of a "move to next thread" binding helps encourage me to form
> good habits. The goal I have when processing my inbox is to get
> everything *out* of my inbox. I can do that by deciding one of several
> common things:
> 
> * I have nothing to do
> 
>   In this case I should just archive the message immediately
> 
> * I can deal with this message "on the spot" (such as a quick reply)
> 
>   In this case, I should deal with the message, then archive it
> 
> * I can't deal with this now, but need to later
> 
>   This is the key scenario. The wrong thing to do is to leave the
>   message in my inbox, (that just makes things pile up and makes
>   my future inbox processing slow, demotivating, and
>   unreliable). The right thing to do is to tag this message in a
>   way that I'm sure I'll find it again when I will be equipped to
>   deal with it. And then I can archive the message.
> 
> So the right answer always involves archiving the message nearly
> immediately, (at most after a quick reply or so), and the keybindings
> encourage archiving over leaving the message in the inbox.
> 
> Of course, one does have an existing keybinding for "move to next
> message in thread without archiving"; it just consists of three key
> presses:
> 
>   'q', 'n', Enter
> 
> At that's long enough to discourage its frequent use.
> 
> So that's a bit of my philosophy and methodology. But like I said, we
> should probably add the obviously missing keybindings so people with
> other philosophies and methodologies can use the program comfortably.
> 
> > Also, just something I have noticed it isn't really obvious that a
> > thread has replies without scrolling down, and that takes time. Would
> > be really good if there could be some big/highlighted visual indicator
> > that there are still unread messages further down.
> 
> That would be good, yes.
> 
> -Carl
> 
> -- 
> carl.d.worth at intel.com
Non-text part: application/pgp-signature
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

100% in agreement.


Besides 1: Keybinds are way too personal to be standardized upon.

This might be of interest to some:
  http://permalink.gmane.org/gmane.comp.misc.suckless/6495

Besides 2: Emacs allows to

patchwork

2011-06-30 Thread Carl Worth 
On Thu, 30 Jun 2011 11:01:14 +0200, martin f krafft  
wrote:
> Are people using http://patchwork.notmuchmail.org at all? The reason
> of my asking is that it receives quite a lot of spam and I do not
> need to invest this time for a service noone uses.

I have not been using it. I dos appreciate your concern for keeping the
notmuch community vibrant and your volunteer efforts to setup this
service.

But if it's costing more time now than it's worth, please feel free to
drop it (unless someone else says differently of course).

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110630/9e56c085/attachment.pgp>

notmuch Digest, Vol 20, Issue 57

2011-06-30 Thread Sebastian Spaeth 
On Tue, 28 Jun 2011 13:22:23 -0700, Carl Worth  wrote:
> First, it's important to understand that any friction here comes from
> Gmail exposing its tags as folders, (which in turn could be the lack of
> availability of a more tag-aware protocol than imap).

Even risking to become a bit thread-offtopic: IMAP itself supports tags
just fine and should be able to read/set/search all tags just fine (even
any user defined). My feeling is more that this is a lack of tag-using
IMAP clients to expose existing tag functionality. Thunderbird is doing
fine exposing up to 4 user-defined tags that are synced to the server,
but it's still not doing all it can.

I still believe that it would be possible to eg. sync all our notmuch
tags to the IMAP server, which would help enormously with syncing across
machines. I still have the long-term goal of offlineimap being able to sync
notmuch tags. (very long term, though)

As for Gmail and folders, I think it is an ugly kludge leading to all
kinds of awkward behavior (at least when treating Gmail as an IMAP
server). On the other hand it exposes nice tag behavior to clients that
wouldn't support it.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110630/0e58d449/attachment-0001.pgp>

[PATCH] remove prefixes from `--output={threads, messages}' results

2011-06-30 Thread Carl Worth 
On Thu, 30 Jun 2011 10:19:49 +0200, Pieter Praet  wrote:
> Alter `do_search_threads()' and `do_search_messages()'
> to not prepend each result with `thread:' respectively `id:'.

My one concern here is that I've sometimes had a message-id without the
id prefix and run a command like this:

notmuch search 1309421989-22410-1-git-send-email-pieter at praet.org

And I've gotten confused when I've received no output, (didn't I receive
that mail? what happened?).

But I think this is a separate bug where the right fix is to make any
search terms with no prefix search through *all* prefixed terms
generated from email content. This would allow us to also avoid indexing
some content twice, (currently we store subject, from, and to both with
a prefix and without a prefix).

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110630/77e20ac2/attachment.pgp>

notmuch Digest, Vol 20, Issue 57

2011-06-30 Thread Pieter Praet 
On Wed, 29 Jun 2011 16:19:44 -0600, Mark Anderson  wrote:
> On Wed, 29 Jun 2011 13:54:40 -0700, Jameson Graef Rollins  finestructure.net> wrote:
> > On Wed, 29 Jun 2011 14:21:11 -0600, Mark Anderson  
> > wrote:
> > > I personally prefer --output=files remain as it was, with one file per
> > > mail (even though I submitted the patch to change it).  I suggest that
> > > we could add another format to supply all files (perhaps
> > > --output=allfiles, or --output=dupfiles).  I don't like my original
> > > suggestion of "filelists" because it implies a list of lists to me.  A
> > > list of lists would correlate better to the number of messages which
> > > match the search terms, but doesn't correlate well to xargs input.
> > 
> > What's wrong with just outputting all the files matching the search,
> > including duplicates?  I can't think of any reason where one would want
> > to not include all files matching the search.  I would be curious to
> > hear a use case there.
> 
> For someone who is using gmail + offlineimap, labels in gmail become
> folders in maildir.
> 
> The maildir structure can have a large number of copies of each email
> corresponding to the labels/tags which have been applied.
> 
> To add a label/tag that is visible to the gmail interface, one should
> copy a file representing the message to the folder representing the
> gmail label, which will then sync to gmail.
> 
> Copying more than one file for each message being labeled is more
> wasteful of time and storage.

Hardlinks to the rescue!

> With all files returned, a simple xargs script to add a label by copying
> files will end up with many copies of the same file in the new
> directory.

Shove in a "head -n 1" ?

> The consuming script could hunt for message-id's in files and uniquify,
> but since notmuch was doing that implicitly before, and it's fairly
> natural, it seems not a big deal to add.
> 
> > Since I'm on this kick anyway, I'm going to keep pushing against further
> > customizations where there really isn't a need.
> 
> With a common use case for the biggest email userbase which makes
> labels/tags natural, I think it is worth considering seriously.
> 
> There are certainly other namesets which could be used to reprecent the
> two categories.  I'm happy to use names that makes the 'allfiles' output
> the common case and the "one file/message" the longer string, but I
> think we should provide the "one file/message" output category.
> 
> The 'allfiles' case is great for deleting all copies of an email, so I
> definitely want it to continue being available.
> 
> -Mark
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Peace

-- 
Pieter

Preventing the user shooting themself in the foot

2011-06-30 Thread Sebastian Spaeth 
On Wed, 29 Jun 2011 15:40:40 -0700, Carl Worth  wrote:
> On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green  
> wrote:
> > It's really dangerous to use the 'a' key in notmuch-mode in an inbox
> > thread which has multiple unread replies! Yes, the other unread replies
> > will still be tagged unread, but the user might not immediately be aware
> > of them. It would be really useful to have an optional warning ("More
> > unread messages in this thread, are you sure?") for this situation!
> 
> That was why I originally designed the space bar keybinding for reading
> through each message in turn, (and then it archives the thread only when you
> page past the last message).
> 
> The 'a' keybinding, (in turn), was designed for cases when you *know*
> you don't want to read the rest of the thread.

And that is what I use 'a' for, please don't take the single-key binding
away for this. I often glance at a thread, decide it's not interesting
for me and archive the whole thread including all unread messages.

It works perfectly for me. Adding another key for "only archive this
message" would be fine. Do people actually use the "x" keybinding? I
know I don't.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110630/c528eef7/attachment.pgp>

[PATCH 1/6] test: run emacs inside screen

2011-06-30 Thread Dmitry Kurochkin 
On Wed, 29 Jun 2011 16:16:40 -0400, Jim Paris  wrote:
> Dmitry Kurochkin wrote:
> > Before the change, emacs run in daemon mode without any visible
> > buffers.  Turns out that this affects emacs behavior in some
> > cases.  In particular, `window-end' function returns `point-max'
> > instead of the last visible position.  That makes it hard or
> > impossible to implement some tests.  The patch runs emacs in a
> > detached screen(1) session.  So that it works exactly as if it
> > has a visible window.
> > 
> > Note: screen terminates when emacs exits.  So the patch does not
> > introduce new "running processes left behind" issues.
> > ---
> >  test/test-lib.sh |   10 --
> >  1 files changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/test/test-lib.sh b/test/test-lib.sh
> > index 079d7db..8d7c98d 100755
> > --- a/test/test-lib.sh
> > +++ b/test/test-lib.sh
> > @@ -873,10 +873,16 @@ EOF
> >  test_emacs () {
> > if [ -z "$EMACS_SERVER" ]; then
> > EMACS_SERVER="notmuch-test-suite-$$"
> > -   "$TMP_DIRECTORY/run_emacs" \
> > -   --daemon \
> > +   # start a detached screen session with an emacs server
> > +   screen -S "$EMACS_SERVER" -d -m "$TMP_DIRECTORY/run_emacs" \
> 
> To avoid problems with ~/.screenrc or /etc/screenrc, you might want e.g.
>   env SYSSCREENRC=/dev/null SCREENRC=/dev/null screen -S ...
> 

Thanks for the suggestion, Jim.  I sent a patch to fix that.

Regards,
  Dmitry

> -jim
> 
> > +   --no-window-system \
> > --eval "(setq server-name \"$EMACS_SERVER\")" \
> > +   --eval '(server-start)' \
> > --eval "(orphan-watchdog $$)" || return
> > +   # wait until the emacs server is up
> > +   until test_emacs '()'; do
> > +   sleep 1
> > +   done
> > fi
> >  
> > emacsclient --socket-name="$EMACS_SERVER" --eval "(progn $@)"
> > -- 
> > 1.7.5.4
> > 
> > ___
> > notmuch mailing list
> > notmuch at notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] test: avoid using screen(1) configuration files

2011-06-30 Thread Dmitry Kurochkin 
Set SCREENRC and SYSSCREENRC environment variables to "/dev/null"
as suggested by Jim Paris to avoid potential problems with
screen(1) configuration files.
---
 test/test-lib.sh |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index 8d7c98d..7cd4832 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -50,6 +50,8 @@ TZ=UTC
 TERM=dumb
 export LANG LC_ALL PAGER TERM TZ
 GIT_TEST_CMP=${GIT_TEST_CMP:-diff -u}
+export SCREENRC=/dev/null
+export SYSSCREENRC=/dev/null

 # Protect ourselves from common misconfiguration to export
 # CDPATH into the environment
-- 
1.7.5.4

[PATCH 1/3] test: `notmuch-show-advance-and-archive' with invisible signature

2011-06-30 Thread Dmitry Kurochkin 
On Wed, 29 Jun 2011 09:10:19 +0400, Dmitry Kurochkin  wrote:
> On Wed, 29 Jun 2011 05:48:50 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > Add Emacs test to check that `notmuch-show-advance-and-archive'
> > works for the last message in thread with invisible signature.
> > ---
> > 
> > This patch series fixes the bug reported by Sebastien in [1].  I
> > was able to reproduce it and confirm that the second patch from
> > this series fixes the problem.  Unfortunately, I can not explain
> > why it fixes it.  The patch uses a cleaner approach for visible
> > text search.  But the old approach should work fine as well.
> > Apparently, it does not work when `invisible' property is not a
> > single symbol but a list (which was changed in
> > 95ef8da29439f2e79115c36ab4d2a80aef1a1462).  I suspect that it is
> > an Emacs bug.  I plan to look at it later.
> > 
> 
> Turns out that `point-invisible-p' is a function from notmuch-lib.el, I
> did not realize that before.  It implements a custom visibility check
> which is incomplete and does not work correctly when `invisible'
> property is a list.  That is why the previous code (which used
> `point-invisible-p') had the bug.  I sent another patch that removes
> `point-invisible-p' function.
> 
> > Another issue is that the test does not demonstrate the bug.
> > Again, I do not really know why.  It passes both before and after
> > the fix.  Although if I run the test commands by hand I hit the
> > bug.  I guess it has something to do with emacs daemon mode when
> > the buffer is not visible.  I hope someone with a better elisp
> > knowledge can tell what is going on and how to make the test
> > work.
> > 
> 
> Now it is clear where the bug was.  Remaining question is how to test
> it.
> 

I have posted a new version of this patch series [1].  It fixes the test
to actually demonstrate the bug.

Regards,
  Dmitry

[1] id:"1309376558-26284-1-git-send-email-dmitry.kurochkin at gmail.com"

> Regards,
>   Dmitry
> 
> > I believe patches 2 and 3 can be pushed after review even without
> > a working test.
> > 
> > Regards,
> >   Dmitry
> > 
> > [1] id:"8739j5rn2d.fsf at cern.ch"
> > 
> >  test/emacs |   12 
> >  1 files changed, 12 insertions(+), 0 deletions(-)
> > 
> > diff --git a/test/emacs b/test/emacs
> > index e59de47..65a96a5 100755
> > --- a/test/emacs
> > +++ b/test/emacs
> > @@ -347,4 +347,16 @@ test_emacs '(notmuch-show 
> > "id:f35dbb950911171438k5df6eb56k77b6c0944e2e79ae at mail.
> > (test-visible-output)'
> >  test_expect_equal_file OUTPUT 
> > $EXPECTED/notmuch-show-thread-with-hidden-messages
> >  
> > +test_begin_subtest 'notmuch-show-advance-and-archive with invisible 
> > signature'
> > +message1='id:20091118010116.GC25380 at dottiness.seas.harvard.edu'
> > +message2='id:1258491078-29658-1-git-send-email-dottedmag at dottedmag.net'
> > +test_emacs "(notmuch-search \"$message1 or $message2\")
> > +   (notmuch-test-wait)
> > +   (notmuch-search-show-thread)
> > +   (notmuch-show-advance-and-archive)
> > +   (test-output)"
> > +test_emacs "(notmuch-show \"$message2\")
> > +   (test-output \"EXPECTED\")"
> > +test_expect_equal_file OUTPUT EXPECTED
> > +
> >  test_done
> > -- 
> > 1.7.5.4
> >

[PATCH 6/6] emacs: remove unused `point-invisible-p' function

2011-06-30 Thread Dmitry Kurochkin 
`point-invisible-p' does not work correctly when `invisible'
property is a list.  There are standard `invisible-p' and related
functions that should be used instead.
---
 emacs/notmuch-lib.el |   15 ---
 1 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index f93c957..0f856bf 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -105,21 +105,6 @@ the user hasn't set this variable with the old or new 
value."

 ;;

-;; XXX: This should be a generic function in emacs somewhere, not
-;; here.
-(defun point-invisible-p ()
-  "Return whether the character at point is invisible.
-
-Here visibility is determined by `buffer-invisibility-spec' and
-the invisible property of any overlays for point. It doesn't have
-anything to do with whether point is currently being displayed
-within the current window."
-  (let ((prop (get-char-property (point) 'invisible)))
-(if (eq buffer-invisibility-spec t)
-   prop
-  (or (memq prop buffer-invisibility-spec)
- (assq prop buffer-invisibility-spec)
-
 (defun notmuch-remove-if-not (predicate list)
   "Return a copy of LIST with all items not satisfying PREDICATE removed."
   (let (out)
-- 
1.7.5.4

[PATCH 5/6] emacs: remove no longer used functions from notmuch-show.el

2011-06-30 Thread Dmitry Kurochkin 
Remove `notmuch-show-move-past-invisible-backward' and
`notmuch-show-move-past-invisible-forward' functions which are
unused.
---
 emacs/notmuch-show.el |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index ad3cc7b..dcaea65 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -977,14 +977,6 @@ All currently available key bindings:
 (notmuch-show-move-to-message-top)
 t))

-(defun notmuch-show-move-past-invisible-forward ()
-  (while (point-invisible-p)
-(forward-char)))
-
-(defun notmuch-show-move-past-invisible-backward ()
-  (while (point-invisible-p)
-(backward-char)))
-
 ;; Functions relating to the visibility of messages and their
 ;; components.

-- 
1.7.5.4

[PATCH 4/6] emacs: improve hidden signatures handling in notmuch-show-advance-and-archive

2011-06-30 Thread Dmitry Kurochkin 
Use `previous-single-char-property-change' instead of going
through each character by hand and testing it's visibility.  This
fixes `notmuch-show-advance-and-archive' to work for the last
message in thread with hidden signature.
---
 emacs/notmuch-show.el |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 6685717..ad3cc7b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1113,17 +1113,18 @@ thread, (remove the \"inbox\" tag from each message). 
Also kill
 this buffer, and display the next thread from the search from
 which this thread was originally shown."
   (interactive)
-  (let ((end-of-this-message (notmuch-show-message-bottom)))
+  (let* ((end-of-this-message (notmuch-show-message-bottom))
+(visible-end-of-this-message (1- end-of-this-message)))
+(while (invisible-p visible-end-of-this-message)
+  (setq visible-end-of-this-message
+   (previous-single-char-property-change visible-end-of-this-message
+ 'invisible)))
 (cond
  ;; Ideally we would test `end-of-this-message' against the result
  ;; of `window-end', but that doesn't account for the fact that
- ;; the end of the message might be hidden, so we have to actually
- ;; go to the end, walk back over invisible text and then see if
- ;; point is visible.
- ((save-excursion
-   (goto-char (- end-of-this-message 1))
-   (notmuch-show-move-past-invisible-backward)
-   (> (point) (window-end)))
+ ;; the end of the message might be hidden.
+ ((and visible-end-of-this-message
+  (> visible-end-of-this-message (window-end)))
   ;; The bottom of this message is not visible - scroll.
   (scroll-up nil))

-- 
1.7.5.4

[PATCH 3/6] test: `notmuch-show-advance-and-archive' with invisible signature

2011-06-30 Thread Dmitry Kurochkin 
Add Emacs test to check that `notmuch-show-advance-and-archive'
works for the last message in thread with invisible signature.
---
 test/emacs |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/test/emacs b/test/emacs
index e59de47..bad1122 100755
--- a/test/emacs
+++ b/test/emacs
@@ -347,4 +347,18 @@ test_emacs '(notmuch-show 
"id:f35dbb950911171438k5df6eb56k77b6c0944e2e79ae at mail.
(test-visible-output)'
 test_expect_equal_file OUTPUT 
$EXPECTED/notmuch-show-thread-with-hidden-messages

+test_begin_subtest 'notmuch-show-advance-and-archive with invisible signature'
+message1='id:20091118010116.GC25380 at dottiness.seas.harvard.edu'
+message2='id:1258491078-29658-1-git-send-email-dottedmag at dottedmag.net'
+test_emacs "(notmuch-search \"$message1 or $message2\")
+   (notmuch-test-wait)
+   (notmuch-search-show-thread)
+   (goto-char (point-max))
+   (redisplay)
+   (notmuch-show-advance-and-archive)
+   (test-output)"
+test_emacs "(notmuch-show \"$message2\")
+   (test-output \"EXPECTED\")"
+test_expect_equal_file OUTPUT EXPECTED
+
 test_done
-- 
1.7.5.4

[PATCH 2/6] test: do not set frame width in emacs

2011-06-30 Thread Dmitry Kurochkin 
No need for `set-frame-width' in emacs tests since it runs in
screen now.
---
 test/test-lib.el |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/test/test-lib.el b/test/test-lib.el
index a783936..97ae593 100644
--- a/test/test-lib.el
+++ b/test/test-lib.el
@@ -20,9 +20,6 @@
 ;;
 ;; Authors: Dmitry Kurochkin 

-;; avoid crazy 10-column default of --batch
-(set-frame-width (window-frame (get-buffer-window)) 80)
-
 ;; `read-file-name' by default uses `completing-read' function to read
 ;; user input.  It does not respect `standard-input' variable which we
 ;; use in tests to provide user input.  So replace it with a plain
-- 
1.7.5.4

[PATCH 1/6] test: run emacs inside screen

2011-06-30 Thread Dmitry Kurochkin 
Before the change, emacs run in daemon mode without any visible
buffers.  Turns out that this affects emacs behavior in some
cases.  In particular, `window-end' function returns `point-max'
instead of the last visible position.  That makes it hard or
impossible to implement some tests.  The patch runs emacs in a
detached screen(1) session.  So that it works exactly as if it
has a visible window.

Note: screen terminates when emacs exits.  So the patch does not
introduce new "running processes left behind" issues.
---
 test/test-lib.sh |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index 079d7db..8d7c98d 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -873,10 +873,16 @@ EOF
 test_emacs () {
if [ -z "$EMACS_SERVER" ]; then
EMACS_SERVER="notmuch-test-suite-$$"
-   "$TMP_DIRECTORY/run_emacs" \
-   --daemon \
+   # start a detached screen session with an emacs server
+   screen -S "$EMACS_SERVER" -d -m "$TMP_DIRECTORY/run_emacs" \
+   --no-window-system \
--eval "(setq server-name \"$EMACS_SERVER\")" \
+   --eval '(server-start)' \
--eval "(orphan-watchdog $$)" || return
+   # wait until the emacs server is up
+   until test_emacs '()'; do
+   sleep 1
+   done
fi

emacsclient --socket-name="$EMACS_SERVER" --eval "(progn $@)"
-- 
1.7.5.4

Re: Preventing the user shooting themself in the foot

2011-06-30 Thread Sebastian Spaeth 
On Wed, 29 Jun 2011 15:40:40 -0700, Carl Worth cwo...@cworth.org wrote:
 On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green gree...@greenrd.org wrote:
  It's really dangerous to use the 'a' key in notmuch-mode in an inbox
  thread which has multiple unread replies! Yes, the other unread replies
  will still be tagged unread, but the user might not immediately be aware
  of them. It would be really useful to have an optional warning (More
  unread messages in this thread, are you sure?) for this situation!
 
 That was why I originally designed the space bar keybinding for reading
 through each message in turn, (and then it archives the thread only when you
 page past the last message).
 
 The 'a' keybinding, (in turn), was designed for cases when you *know*
 you don't want to read the rest of the thread.

And that is what I use 'a' for, please don't take the single-key binding
away for this. I often glance at a thread, decide it's not interesting
for me and archive the whole thread including all unread messages.

It works perfectly for me. Adding another key for only archive this
message would be fine. Do people actually use the x keybinding? I
know I don't.

Sebastian


pgpcFaQ23hAUm.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch Digest, Vol 20, Issue 57

2011-06-30 Thread Pieter Praet 
On Wed, 29 Jun 2011 16:19:44 -0600, Mark Anderson ma.sk...@gmail.com wrote:
 On Wed, 29 Jun 2011 13:54:40 -0700, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
  On Wed, 29 Jun 2011 14:21:11 -0600, Mark Anderson ma.sk...@gmail.com 
  wrote:
   I personally prefer --output=files remain as it was, with one file per
   mail (even though I submitted the patch to change it).  I suggest that
   we could add another format to supply all files (perhaps
   --output=allfiles, or --output=dupfiles).  I don't like my original
   suggestion of filelists because it implies a list of lists to me.  A
   list of lists would correlate better to the number of messages which
   match the search terms, but doesn't correlate well to xargs input.
  
  What's wrong with just outputting all the files matching the search,
  including duplicates?  I can't think of any reason where one would want
  to not include all files matching the search.  I would be curious to
  hear a use case there.
 
 For someone who is using gmail + offlineimap, labels in gmail become
 folders in maildir.
 
 The maildir structure can have a large number of copies of each email
 corresponding to the labels/tags which have been applied.
 
 To add a label/tag that is visible to the gmail interface, one should
 copy a file representing the message to the folder representing the
 gmail label, which will then sync to gmail.
 
 Copying more than one file for each message being labeled is more
 wasteful of time and storage.

Hardlinks to the rescue!

 With all files returned, a simple xargs script to add a label by copying
 files will end up with many copies of the same file in the new
 directory.

Shove in a head -n 1 ?

 The consuming script could hunt for message-id's in files and uniquify,
 but since notmuch was doing that implicitly before, and it's fairly
 natural, it seems not a big deal to add.
 
  Since I'm on this kick anyway, I'm going to keep pushing against further
  customizations where there really isn't a need.
 
 With a common use case for the biggest email userbase which makes
 labels/tags natural, I think it is worth considering seriously.
 
 There are certainly other namesets which could be used to reprecent the
 two categories.  I'm happy to use names that makes the 'allfiles' output
 the common case and the one file/message the longer string, but I
 think we should provide the one file/message output category.
 
 The 'allfiles' case is great for deleting all copies of an email, so I
 definitely want it to continue being available.
 
 -Mark
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch

Peace

-- 
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch Digest, Vol 20, Issue 57

2011-06-30 Thread Sebastian Spaeth 
On Tue, 28 Jun 2011 13:22:23 -0700, Carl Worth cwo...@cworth.org wrote:
 First, it's important to understand that any friction here comes from
 Gmail exposing its tags as folders, (which in turn could be the lack of
 availability of a more tag-aware protocol than imap).

Even risking to become a bit thread-offtopic: IMAP itself supports tags
just fine and should be able to read/set/search all tags just fine (even
any user defined). My feeling is more that this is a lack of tag-using
IMAP clients to expose existing tag functionality. Thunderbird is doing
fine exposing up to 4 user-defined tags that are synced to the server,
but it's still not doing all it can.

I still believe that it would be possible to eg. sync all our notmuch
tags to the IMAP server, which would help enormously with syncing across
machines. I still have the long-term goal of offlineimap being able to sync
notmuch tags. (very long term, though)

As for Gmail and folders, I think it is an ugly kludge leading to all
kinds of awkward behavior (at least when treating Gmail as an IMAP
server). On the other hand it exposes nice tag behavior to clients that
wouldn't support it.

Sebastian


pgpAlsJ9EmTiG.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet 
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
 On Thu, 30 Jun 2011 13:04:23 +1000, Brian May 
 br...@microcomaustralia.com.au wrote:
  On 30 June 2011 08:40, Carl Worth cwo...@cworth.org wrote:
   The 'a' keybinding, (in turn), was designed for cases when you *know*
   you don't want to read the rest of the thread.
  
  ... in which case it should also mark everything as read. IMHO.
 
 I know the current behavior only catches my opinion (and only an opinion
 I had at one particular point in time). So I won't say this is Right,
 but I will at least explain what I was thinking:
 
 The unread tag is distinct from the inbox tag. Why two tags? Don't
 they normally change at the same time? If a key like 'a' got rid of the
 unread tag as well as the inbox then there would be almost no need
 for having two tags.
 
 The idea I had is that inbox is fully under explicit control by the
 user. The user must make an intentional decision to archive a message
 in order for that tag to be removed.
 
 Distinct from that is unread which is handled automatically by the
 mail client (as well as it can tell what you've actually read or
 not). So this tag is removed only implicitly, (we don't have specific
 commands to manipulate the unread tag). When the client displays a
 message as the current message it immediately removes the unread
 tag.
 
  Whenever it displays a message to the
 user, (as the current message), it removes the unread tag from that
 message.
 
 This means that messages can lose the unread tag while still remaining
 tagged inbox, (you read a message, but don't archive it), and that
 messages can lose the archive tag while still remaining tagged
 unread, (you archive a thread before reading all messages in the
 thread).
 
 The distinction ends up being useful to me. If at some point someone
 points me to a specific message, and when I search for it I see the
 unread tag, then this highlights to me that I never even looked at the
 message.
 
  Are there any keyboard bindings to go forwards to the next message or
  backwards to the last message without marking anything as archived?
 
 As mentioned by someone else, you can navigate the messages in a thread
 with 'n' and 'p'.
 
 One of the obviously missing keybindings is a way to easily navigate
 From the current thread to the next thread without archiving the current
 thread. We should probably add that keybinding at some point, but I want
 to at least point out why I didn't create it originally:
 
 The lack of a move to next thread binding helps encourage me to form
 good habits. The goal I have when processing my inbox is to get
 everything *out* of my inbox. I can do that by deciding one of several
 common things:
 
 * I have nothing to do
 
   In this case I should just archive the message immediately
 
 * I can deal with this message on the spot (such as a quick reply)
 
   In this case, I should deal with the message, then archive it
 
 * I can't deal with this now, but need to later
 
   This is the key scenario. The wrong thing to do is to leave the
   message in my inbox, (that just makes things pile up and makes
   my future inbox processing slow, demotivating, and
   unreliable). The right thing to do is to tag this message in a
   way that I'm sure I'll find it again when I will be equipped to
   deal with it. And then I can archive the message.
 
 So the right answer always involves archiving the message nearly
 immediately, (at most after a quick reply or so), and the keybindings
 encourage archiving over leaving the message in the inbox.
 
 Of course, one does have an existing keybinding for move to next
 message in thread without archiving; it just consists of three key
 presses:
 
   'q', 'n', Enter
 
 At that's long enough to discourage its frequent use.
 
 So that's a bit of my philosophy and methodology. But like I said, we
 should probably add the obviously missing keybindings so people with
 other philosophies and methodologies can use the program comfortably.
 
  Also, just something I have noticed it isn't really obvious that a
  thread has replies without scrolling down, and that takes time. Would
  be really good if there could be some big/highlighted visual indicator
  that there are still unread messages further down.
 
 That would be good, yes.
 
 -Carl
 
 -- 
 carl.d.wo...@intel.com
Non-text part: application/pgp-signature
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch

100% in agreement.


Besides 1: Keybinds are way too personal to be standardized upon.

This might be of interest to some:
  http://permalink.gmane.org/gmane.comp.misc.suckless/6495

Besides 2: Emacs allows to tailor *anything and everything* to
your needs, on the spot, in realtime (reflection and all that).


Peace

-- 
Pieter

Re: Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet 
On Wed, 29 Jun 2011 19:53:03 -0400, Austin Clements amdra...@mit.edu wrote:
Non-text part: multipart/mixed
Non-text part: multipart/alternative
 I've spent embarrassingly little time in the emacs UI, so my opinions on
 this should be taken lightly, but I feel like all of the bindings are of the
 form if W, do X and Y, otherwise do Z and, as a result, I'm actively
 afraid of what's going to happen when I hit a key. I would much prefer
 bindings with simple, highly predictable behavior. I'm sure there's some
 workflow for which these contextual, compound bindings are fantastic, but
 other workflows wind up fighting against them.

Very true!

 I don't have a specific proposal in mind, but Gmail's bindings seem like a
 good model to emulate (the actions, at least; I've never been too fond of
 the specific key choices).

+1

And AFAIK, Archive does *not* mark a message as read in GMail.
(see previous messages suggesting the inverse)

 On Jun 29, 2011 6:40 PM, Carl Worth cwo...@cworth.org wrote:
Non-text part: text/html
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 4/4] emacs: Add pseudo tag to match all messages that have no tags

2011-06-30 Thread Pieter Praet 
On Tue, 28 Jun 2011 07:31:32 +, Jani Nikula j...@nikula.org wrote:
 Add a pseudo tag that matches all the messages that have no tags. Add new
 customization option notmuch-tags-nomatch to enable and name the pseudo
 tag.
 ---
  emacs/notmuch-hello.el |   18 --
  1 files changed, 16 insertions(+), 2 deletions(-)
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index b9c9b01..1770f60 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -53,6 +53,12 @@
string)
:group 'notmuch)
  
 +(defcustom notmuch-tags-nomatch nil
 +  Name of the pseudo tag to match messages that have no tags.
 +  :type '(choice (const :tag Off nil)
 +  string)
 +  :group 'notmuch)
 +
  (defvar notmuch-hello-indent 4
How much to indent non-headers.)
  
 @@ -352,7 +358,7 @@ Complete list of currently available key bindings:
  
  (defun notmuch-hello-generate-tag-alist ()
Return an alist from tags to queries to display in the all-tags section.
 -  (notmuch-remove-if-not
 +  (let ((tag-alist (notmuch-remove-if-not
 #'cdr
 (mapcar (lambda (tag)
(cons tag
 @@ -367,7 +373,15 @@ Complete list of currently available key bindings:
  (notmuch-remove-if-not
   (lambda (tag)
 (not (member tag notmuch-hello-hide-tags)))
 - (process-lines notmuch-command search-tags)
 + (process-lines notmuch-command search-tags))
 +(when notmuch-tags-nomatch
 +  (let ((no-tag-search
 +  (cons notmuch-tags-nomatch
 +(mapconcat (lambda (arg) (concat (not ( (cdr arg)  
 tag-alist  and 
 + (if ( (string-to-number (notmuch-saved-search-count (cdr 
 no-tag-search))) 0)
 + ;; Append the no-match search.
 + (add-to-list 'tag-alist no-tag-search t
 +tag-alist))
  
  (defun notmuch-hello-saved-alist ()
(if notmuch-saved-searches
 -- 
 1.7.1
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


IMHO, this should be handled in notmuch core.

eg.
  `notmuch search tag:*' matches all tagged
  `notmuch search tag:'  matches all non-tagged.

- No need for an extra customization option in Emacs,
   just a simple saved search.

Opinions?


Peace

-- 
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] remove prefixes from `--output={threads,messages}' results

2011-06-30 Thread Pieter Praet 
Alter `do_search_threads()' and `do_search_messages()'
to not prepend each result with `thread:' respectively `id:'.

This makes its output consistent with `do_search_tags()'.

See this discussion: id:871v6b79s0@yoom.home.cworth.org



NOTE:

I started adjusting the tests as well, but stopped fairly quickly since
the amount is simply *ludicrous*. Only 9 tests fail initially, but start
ripping out `notmuch_search_sanitize' (as would be sensible) and you'll
see what I mean.

Time isn't the issue (sed flies through it faster than Windoze can BSOD),
but the patch will be so huge and disruptive that even Ubuntu devs might
consider frowning disapprovingly.



Signed-off-by: Pieter Praet pie...@praet.org
---
 notmuch-search.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/notmuch-search.c b/notmuch-search.c
index faccaf7..c565ae6 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -220,7 +220,7 @@ do_search_threads (const search_format_t *format,
thread = notmuch_threads_get (threads);
 
if (output == OUTPUT_THREADS) {
-   format-item_id (thread, thread:,
+   format-item_id (thread, ,
 notmuch_thread_get_thread_id (thread));
} else { /* output == OUTPUT_SUMMARY */
fputs (format-item_start, stdout);
@@ -312,7 +312,7 @@ do_search_messages (const search_format_t *format,
if (! first_message)
fputs (format-item_sep, stdout);
 
-   format-item_id (message, id:,
+   format-item_id (message, ,
 notmuch_message_get_message_id (message));
first_message = 0;
}
-- 
1.7.4.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] add `tag:' prefix to `--output=tags' results

2011-06-30 Thread Pieter Praet 
Alter `do_search_tags()' to prepend each result with `tag:',
and update affected test.

This makes its output consistent with `do_search_threads()' and
`do_search_messages()'.

See this discussion: id:871v6b79s0@yoom.home.cworth.org

Signed-off-by: Pieter Praet pie...@praet.org
---
 notmuch-search.c   |2 +-
 test/search-output |8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/notmuch-search.c b/notmuch-search.c
index faccaf7..5b91a40 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -364,7 +364,7 @@ do_search_tags (notmuch_database_t *notmuch,
if (! first_tag)
fputs (format-item_sep, stdout);
 
-   format-item_id (tags, , tag);
+   format-item_id (tags, tag:, tag);
 
first_tag = 0;
 }
diff --git a/test/search-output b/test/search-output
index 10291c3..37f1b3d 100755
--- a/test/search-output
+++ b/test/search-output
@@ -289,10 +289,10 @@ test_expect_equal_file OUTPUT EXPECTED
 test_begin_subtest --output=tags
 notmuch search --output=tags '*' OUTPUT
 cat EOF EXPECTED
-attachment
-inbox
-signed
-unread
+tag:attachment
+tag:inbox
+tag:signed
+tag:unread
 EOF
 test_expect_equal_file OUTPUT EXPECTED
 
-- 
1.7.4.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: add keybind and function to stash Message-ID without prefix

2011-06-30 Thread Pieter Praet 
Add function `notmuch-show-stash-message-id-stripped'
which stashes a Message-ID after ripping off the prefix and quotes,
add bind it to I key in `notmuch-show-stash-map'.

Simplifying `notmuch-show-get-message-id' instead might seem better,
but that would require concat'ing in 9 places instead of 1.

Signed-off-by: Pieter Praet pie...@praet.org
---
 emacs/notmuch-show.el |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 6685717..a703732 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -858,6 +858,7 @@ function is used. 
 (define-key map F 'notmuch-show-stash-filename)
 (define-key map f 'notmuch-show-stash-from)
 (define-key map i 'notmuch-show-stash-message-id)
+(define-key map I 'notmuch-show-stash-message-id-stripped)
 (define-key map s 'notmuch-show-stash-subject)
 (define-key map T 'notmuch-show-stash-tags)
 (define-key map t 'notmuch-show-stash-to)
@@ -1408,6 +1409,11 @@ buffer.
   (interactive)
   (notmuch-common-do-stash (notmuch-show-get-message-id)))
 
+(defun notmuch-show-stash-message-id-stripped ()
+  Copy message ID of current message (sans `id:' prefix) to kill-ring.
+  (interactive)
+  (notmuch-common-do-stash (substring (notmuch-show-get-message-id) 4 -1)))
+
 (defun notmuch-show-stash-subject ()
   Copy Subject field of current message to kill-ring.
   (interactive)
-- 
1.7.4.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] test: stashing in notmuch-{show,search}

2011-06-30 Thread Pieter Praet 
Should provide full test coverage of the stashing feature.

Signed-off-by: Pieter Praet pie...@praet.org
---
 test/emacs|   41 +
 test/emacs.expected-output/emacs-stashing |9 ++
 2 files changed, 50 insertions(+), 0 deletions(-)
 create mode 100644 test/emacs.expected-output/emacs-stashing

diff --git a/test/emacs b/test/emacs
index 53f455a..46076c6 100755
--- a/test/emacs
+++ b/test/emacs
@@ -347,4 +347,45 @@ test_emacs '(notmuch-show 
id:f35dbb950911171438k5df6eb56k77b6c0944e2e79ae@mail.
(test-visible-output)'
 test_expect_equal_file OUTPUT 
$EXPECTED/notmuch-show-thread-with-hidden-messages
 
+test_begin_subtest Stashing in notmuch-show
+add_message '[date]=Sat, 01 Jan 2000 12:00:00 -' \
+'[from]=Some One some...@somewhere.org' \
+'[to]=Some One Else notsome...@somewhere.org' \
+'[cc]=Notmuch notmuch@notmuchmail.org' \
+'[subject]=Stash my stashables' \
+'[id]=bought' \
+'[body]=Unable to stash body. Where did you get it in the first place?!?'
+notmuch tag +stashtest id:${gen_msg_id}
+test_emacs '(notmuch-show id:\bought\)
+(notmuch-show-stash-date)
+(notmuch-show-stash-from)
+(notmuch-show-stash-to)
+(notmuch-show-stash-cc)
+(notmuch-show-stash-subject)
+(notmuch-show-stash-message-id)
+(notmuch-show-stash-message-id-stripped)
+(notmuch-show-stash-tags)
+(notmuch-show-stash-filename)
+(switch-to-buffer
+  (generate-new-buffer *test-stashing*))
+(dotimes (i 9)
+  (yank)
+  (insert \n)
+  (rotate-yank-pointer 1))
+(reverse-region (point-min) (point-max))
+   (test-output)'
+sed -i -e 's/^.*tmp.emacs\/mail.*$/FILENAME/' OUTPUT
+test_expect_equal_file OUTPUT $EXPECTED/emacs-stashing
+
+test_begin_subtest Stashing in notmuch-search
+test_emacs '(notmuch-search id:\bought\)
+(notmuch-test-wait)
+(notmuch-search-stash-thread-id)
+(switch-to-buffer
+  (generate-new-buffer *test-stashing*))
+(yank)
+   (test-output)'
+sed -i -e 's/^thread:.*$/thread:XXX/' OUTPUT
+test_expect_equal $(cat OUTPUT) thread:XXX
+
 test_done
diff --git a/test/emacs.expected-output/emacs-stashing 
b/test/emacs.expected-output/emacs-stashing
new file mode 100644
index 000..4923594
--- /dev/null
+++ b/test/emacs.expected-output/emacs-stashing
@@ -0,0 +1,9 @@
+Sat, 01 Jan 2000 12:00:00 -
+Some One some...@somewhere.org
+Some One Else notsome...@somewhere.org
+Notmuch notmuch@notmuchmail.org
+Stash my stashables
+id:bought
+bought
+inbox,stashtest
+FILENAME
-- 
1.7.4.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet 
On Thu, 30 Jun 2011 09:50:27 +0200, Pieter Praet pie...@praet.org wrote:
 [...]
 And AFAIK, Archive does *not* mark a message as read in GMail.
 (see previous messages suggesting the inverse [...]
... be implemented in Notmuch.

 [...] )

Nobody claimed the inverse was the case in GMail, so I created the wrong
impression. I should've picked my words more carefully.


Peace

-- 
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

patchwork

2011-06-30 Thread martin f krafft 
Are people using http://patchwork.notmuchmail.org at all? The reason
of my asking is that it receives quite a lot of spam and I do not
need to invest this time for a service noone uses.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
'oh, that was easy,' says Man, and for an encore goes on to prove
 that black is white and gets himself killed on the next zebra
 crossing.
-- douglas adams, the hitchhiker's guide to the galaxy
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch