problem with message/rfc822 parts
today I updated to the latest git version of notmuch, which mostly works as expected. However, I now have the problem that whenever I look via emacs interface at a message which contains an embedded message/rfc822 part (like a forwarded message), then I just see "[ message/rfc822 ]" in the display buffer. I would expect that I am somehow able to access/view the forwarded message from the emacs interface, however I do not know how to achieve this. This worked fine with notmuch versions from April, but somehow it seems to be broken now for me. Is this a known problem or do I need some configuration magic? Any hints for debugging this would be welcome. Andreas
Possible bug: wrong from address when forwarding
Hi I am seeing the following bug in the emacs interface: when I forward a message (f when showing a message) I get a message with the from address filled in by the host operating system (walters at hostname) rather than my notmuch configured address. If I compose mail normally notmuch fills in the correct (notmuch configured) address. The problem could be in my setup but as far as I can see in notmuch-mua.el notmuch-mua-forward-message and notmuch-mua-mail behave differently: the latter fills in the from header with notmuch-user-primary-email and the former does not. Mark
[PATCH] NEWS: spellcheck notes for notmuch 0.6 resease
Just fix some typos in the recently added NEWS for notmuch 0.6 release. --- NEWS | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/NEWS b/NEWS index d55453b..d9ffb02 100644 --- a/NEWS +++ b/NEWS @@ -79,13 +79,13 @@ Deprecate "notmuch search-tags", (in favor of "notmuch search --output=tags *") Performance improvements -Faster searches (by doing fewer serches to construct threads) +Faster searches (by doing fewer searches to construct threads) Whenever a user asks for search results as threads, notmuch first performs a search for messages matching the query, then performs additional searches to find other messages in the resulting threads. - Removing inefficiences and redundancies in these secondary searches + Removing inefficiencies and redundancies in these secondary searches results in a measured speedups of 1.5x for a typical search. Faster searches (by doing fewer passes to gather message data) @@ -130,7 +130,7 @@ User-selectable From address will prompt for the from address to use. The user can customize the "Notmuch Identities" setting in the - notmuch cutomize group in order to use addresses other than those in + notmuch customize group in order to use addresses other than those in the notmuch configuration file if desired. The user can also choose to always be prompted for the from address @@ -154,7 +154,7 @@ New hooks for running code when tags are modified Some users want to perform additional actions whenever a particular tag is added/removed from a message. This could be used to, for example, interface with some external spam-recognition training - tool. T facilitate this, two new hooks are added which can be + tool. To facilitate this, two new hooks are added which can be modified in the following settings of the notmuch customize group: Notmuch Before Tag Hook @@ -181,7 +181,7 @@ Better rendering of text/x-vcalendar parts Avoid getting confused by Subject and Author fields with newline characters - Replacing all characters with ACII code less than 32 with a question mark. + Replacing all characters with ASCII code less than 32 with a question mark. Cleaner display of From line in email messages (remove double quotes, and drop "name" if it's actually just a repeat of the email address). @@ -254,17 +254,17 @@ Binary for bash for running test suite now located via PATH. bash 4). As some systems supply an older version of bash at /bin/bash, the test suite is now updated to search $PATH to locate the bash binary. This allows users of systems with old /bin/bash to - simply install bash >= 4 somwhere on $PATH before /bin and then use + simply install bash >= 4 somewhere on $PATH before /bin and then use the test suite. Support for testing output with a trailing newline. Previously, some tests would fail to notice a difference in the - presense/absence of a trailing newline in a program output, (which + presence/absence of a trailing newline in a program output, (which has led to bugs in the past). Now, carefully-written tests (using test_expect_equal_file rather than test_expect_equal) will detect any change in the presence/absence of a trailing newline. Many tests - are updated to take advnatage of this. + are updated to take advantage of this. Avoiding accessing user's $HOME while running test suite @@ -313,7 +313,7 @@ Fix libnotmuch library to only export notmuch API functions Previous release of the notmuch library also exported some Xapian C++ exception type symbols. These were never part of the library - interface and were never intented to be exported. + interface and were never intended to be exported. Emacs-interface bug fixes - @@ -321,16 +321,16 @@ Display any unexpected output or errors from "notmuch search" invocations Previously any misformatted output or trailing error messages were silently ignored. This output is now clearly displayed. This fix was - very helpful in identifying and fixing the bug decribed below. + very helpful in identifying and fixing the bug described below. Fix bug where some threads would be missing from large search results When a search returned a "large" number of results, the emacs - interface was incorrectly dropping one thread everytime the output - of the "notmuch search" process spanned the emacss read-buffer. This + interface was incorrectly dropping one thread every time the output + of the "notmuch search" process spanned the emacs read-buffer. This is now fixed. -Avoid rec-compression of .gz files (and similar) when saving attachment +Avoid re-compression of .gz files (and similar) when saving attachment Emacs was being too clever for its own good and trying to re-compress pre-compressed .gz files when saving such attachments -- 1.7.5.4
branchs and tags and merges oh my!
On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard wrote:
> > 2) merge master onto the release branch
>
> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.
Can you elaborate? Naively it seems like one ends up with the same kind
of spur of history off of the 0.6 tag in both cases.
.--master
\
0.6 bugfix
versus
-.--.
\ \
0.6master
\
- bugfix
> As an alternative, you probably should have simply put non-release
> patches on a separate 'feature branch' (probably residing in the feature
> author's repository) which would then be merged onto master post-0.6
Yes, that is certainly nice from a git history point of view. On the
other hand the point of separating the roles of feature merger from
release mechanic was to allow Carl more time to work on merging features
into master, and I'm not sure how turning master over to the release
manager helps that.
David
-- 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/20110701/de55cd63/attachment.pgp>
Preventing the user shooting themself in the foot
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle wrote: > On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth wrote: > Non-text part: multipart/mixed > Non-text part: multipart/signed > > not sure why notmuch reply is putting that there :) > > > 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. > > I'm come to strongly agree that this is the Right Way to process email > too, so should there be a keybinding for this last operation? It should > tag the message (or the thread?) with, say, 'task', and then proceeded > as 'a' does. 'task' should be in the default searches you get in > the notmuch hello buffer. #+BEGIN_SRC emacs-lisp (define-key notmuch-show-mode-map "t" (lambda() "Flag and archive currently selected message, and move to the next. If this is the last message, move to the next thread." (interactive) (notmuch-show-add-tag "flagged") (notmuch-show-advance-and-archive))) #+END_SRC Note that I use the "flagged" tag, since this corresponds to a maildir flag, and can be synced via IMAP. > I realize there is endless bikeshedding to be done on tag names and so > on and also on allowing people to choose their own workflow, but I also > think that this shouldn't stop the addition of a sensible default :) > > Cheers, > mwh > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter
branchs and tags and merges oh my!
Much to everyone's relief, 0.6 is finally released.
problem with message/rfc822 parts
On Fri, 01 Jul 2011 22:07:38 +0100, Andreas Amann wrote: > This worked fine with notmuch versions from April, but somehow it seems > to be broken now for me. Is this a known problem or do I need some > configuration magic? Any hints for debugging this would be welcome. Hi Andreas; It's a known problem. As a short term fix, try the patches of id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net" David
Gnus (nnml) + notmuch
Hi. Has anyone integrated Gnus (with nnml: groups) and notmuch (for instance using the org-gnus-follow-link way described by Tassilo Horn [0] ? I'm concerned with "automatically" tagging mails split in groups by nnmail-split-methods with their group names, handling read/unread marks (and more), and of course reading/responding to mails in the most straightforward way with Gnus modes. Many thanks in advance. Best regards, [0] http://article.gmane.org/gmane.emacs.gnus.user/13308 -- Olivier BERGER (OpenPGP: 4096R/7C5BB6A5) http://www.olivierberger.com/weblog/
branchs and tags and merges oh my!
On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner wrote: > 1) repeat the whole thing with a new release branch for 0.7 and end up > with > > --.--.--- master >\ \ > - 0.6 --- 0.7 That's the 'usual' plan followed by projects which use a central repository. > 2) merge master onto the release branch > > > ---..- master > \\ / > -.. 0.7 > 0.6 now freeze This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging. As an alternative, you probably should have simply put non-release patches on a separate 'feature branch' (probably residing in the feature author's repository) which would then be merged onto master post-0.6, in the 'merge window' plan. That's the usual plan followed by projects using multiple repositories and time-based releases. With this model, you simply release from master when the time comes. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110701/4fa373ee/attachment.pgp>
[SCM] notmuch - thread-based email index, search and tagging. annotated tag, 0.6, created. 0.6
On Fri, 1 Jul 2011 13:13:27 -0700 (PDT), notmuch-commits-sender at notmuchmail.org (David Bremner) wrote: > The annotated tag, 0.6 has been created > at 6eae40d57f12bb44d1b375a1d37454974f6dafd2 (tag) >tagging 6bd02fb4dbee9e0fc372661af573a2ac380fed8a (commit) > replaces 0.6rc1 > tagged by David Bremner > on Fri Jul 1 17:08:59 2011 -0300 > > - Log - > notmuch 0.6 release w00t! Three cheers for the Release Tyrant! Long live the Release Tyrant! Here's to releasing 0.7 before 2012! jamie.
Preventing the user shooting themself in the foot
On Fri, Jul 1, 2011 at 12:37 PM, Jameson Graef Rollins wrote: > On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle canonical.com> wrote: >> On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth wrote: >> I'm come to strongly agree that this is the Right Way to process email >> too, so should there be a keybinding for this last operation? ?It should >> tag the message (or the thread?) with, say, 'task', and then proceeded >> as 'a' does. ?'task' should be in the default searches you get in >> the notmuch hello buffer. > > While I agree that Carl's method is pretty good, there is absolutely no > "Right Way" to process email; it's a completely personal, subjective > thing. ?"Right Way" implies to me that other people *should* be > processing their mail that way, which I disagree with. > > I'm generally against excessive unneeded configuration, but in the case > of key bindings it's definitely necessary. ?Fortunately emacs is so > fundamentally flexible one can always modify the keybindings to their > hearts content. While that's true and opens endless possibilities for power users, the defaults need to be suited to new users. Nobody wants to use a tool that takes endless configuration just to get started, especially since that's when you least know what configuration you want. Simple bindings with predictable behaviors that allow users to express their own workflow, even if it requires a few more keystrokes, make better defaults than bindings that codify a particular workflow. As users become more adept at a tool, this enables them to *incrementally* capture (and refine) their workflow as more optimized bindings.
[PATCH 2/2] [RFC] possible solution for "Race condition for '*' command"
On Jul 1, 2011 10:55 AM, "Austin Clements" wrote: > > On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet wrote: > > 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" > > Ideally, this wouldn't be per-buffer, but per *line*. This race > equally affects adding and removing tags from individual results, > since that's done using a thread: query, whose results could have > changed since the original search. > > This almost certainly requires support from the notmuch core. The > good news is that the library already provides this information, so > there will be virtually no performance hit for outputting it. Actually, with a smidgeon of library support, you could even use document IDs for this, rather than message IDs, which would make the tagging operations (even '*') no more expensive than they are now. (Of course, it would be good to know just how much overhead going through message IDs actually introduces.) -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110701/b66038b3/attachment.html>
Preventing the user shooting themself in the foot
On 30 June 2011 17:50, Pieter Praet wrote: > And AFAIK, "Archive" does *not* mark a message as read in GMail. > (see previous messages suggesting the inverse) gmail will mark all messages in the thread as read when looking at any part of the thread - so in practical terms whenever I click "Archive" the entire thread is marked as read - as I always click archive in the message view. Not absolutely convinced this is the best approach. I think it is important to appreciate the differences that different implementations have chosen. -- Brian May
[PATCH 2/2] [RFC] possible solution for "Race condition for '*' command"
On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet wrote: > 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" Ideally, this wouldn't be per-buffer, but per *line*. This race equally affects adding and removing tags from individual results, since that's done using a thread: query, whose results could have changed since the original search. This almost certainly requires support from the notmuch core. The good news is that the library already provides this information, so there will be virtually no performance hit for outputting it.
Preventing the user shooting themself in the foot
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle wrote: > On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth wrote: > Non-text part: multipart/mixed > Non-text part: multipart/signed > > not sure why notmuch reply is putting that there :) They shouldn't be, and I sent a patch to fix that a while ago: id:"1307561409-5646-3-git-send-email-jrollins at finestructure.net" But of course feel free to delete them before sending. > I'm come to strongly agree that this is the Right Way to process email > too, so should there be a keybinding for this last operation? It should > tag the message (or the thread?) with, say, 'task', and then proceeded > as 'a' does. 'task' should be in the default searches you get in > the notmuch hello buffer. While I agree that Carl's method is pretty good, there is absolutely no "Right Way" to process email; it's a completely personal, subjective thing. "Right Way" implies to me that other people *should* be processing their mail that way, which I disagree with. I'm generally against excessive unneeded configuration, but in the case of key bindings it's definitely necessary. Fortunately emacs is so fundamentally flexible one can always modify the keybindings to their hearts content. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110701/a2190f6d/attachment.pgp>
Preventing the user shooting themself in the foot
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth wrote: Non-text part: multipart/mixed Non-text part: multipart/signed not sure why notmuch reply is putting that there :) > 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. I'm come to strongly agree that this is the Right Way to process email too, so should there be a keybinding for this last operation? It should tag the message (or the thread?) with, say, 'task', and then proceeded as 'a' does. 'task' should be in the default searches you get in the notmuch hello buffer. I realize there is endless bikeshedding to be done on tag names and so on and also on allowing people to choose their own workflow, but I also think that this shouldn't stop the addition of a sensible default :) Cheers, mwh
Preventing the user shooting themself in the foot
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth wrote: > 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. IMHO this is one of the awesome things about notmuch (and I've actively used it to go back on conversations I previously ignored) -- Stewart Smith
[PATCH v2 7/7] emacs: remove unused `point-invisible-p' function
`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 v2 6/7] emacs: remove no longer used functions from notmuch-show.el
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 v2 5/7] emacs: improve hidden signatures handling in notmuch-show-advance-and-archive
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 v2 4/7] test: `notmuch-show-advance-and-archive' with invisible signature
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 53f455a..708c504 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 v2 3/7] test: do not set frame width in emacs
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 v2 2/7] test: avoid using screen(1) configuration files
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 688598c..0608e42 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 v2 0/7] advance-and-archive bugfix, run emacs inside screen
Amended patch series. Only minor changes: * redirect errors from test_emacs in the emacs server wait loop to /dev/null * reordered patches Regards, Dmitry
[PATCH] test: do not hide test_emacs errors
Do not redirect test_emacs stderr to /dev/null. Test_emacs uses
emacsclient(1) now and it does not print unwanted messages (like
those from `message') to stderr. But it does print useful
errors, e.g. when emacs server connection fails, given expression
is not valid or undefined function is called.
---
test/emacs |4 ++--
test/test-lib.sh |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/test/emacs b/test/emacs
index 53f455a..dbe8d9e 100755
--- a/test/emacs
+++ b/test/emacs
@@ -261,13 +261,13 @@ test_begin_subtest "Save attachment from within emacs
using notmuch-show-save-at
# save as archive to test that Emacs does not re-compress .gz
test_emacs '(let ((standard-input "\"attachment1.gz\""))
(notmuch-show "id:cf0c4d610911171136h1713aa59w9cf9aa31f052ad0a at
mail.gmail.com")
- (notmuch-show-save-attachments))' > /dev/null 2>&1
+ (notmuch-show-save-attachments))'
test_expect_equal_file attachment1.gz "$EXPECTED/attachment"
test_begin_subtest "Save attachment from within emacs using
notmuch-show-save-part"
# save as archive to test that Emacs does not re-compress .gz
test_emacs '(let ((standard-input "\"attachment2.gz\""))
- (notmuch-show-save-part
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052ad0a at mail.gmail.com" 5))' >
/dev/null 2>&1
+ (notmuch-show-save-part
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052ad0a at mail.gmail.com" 5))'
test_expect_equal_file attachment2.gz "$EXPECTED/attachment"
test_begin_subtest "View raw message within emacs"
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 22e387e..37f007a 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -394,7 +394,7 @@ emacs_deliver_message ()
(message-goto-body)
(insert \"${body}\")
$@
- (message-send-and-exit))" >/dev/null 2>&1
+ (message-send-and-exit))"
wait ${smtp_dummy_pid}
notmuch new >/dev/null
}
--
1.7.5.4
[PATCH] test: json show format of message with inline attachment with filename
The patch adds a test to check that json show format includes
filenames for attachments with inline disposition.
---
Carl, I owe you this test case for my patch that added filenames
for inline attachments :)
Regards,
Dmitry
test/json | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/test/json b/test/json
index 5a2544c..592b068 100755
--- a/test/json
+++ b/test/json
@@ -23,6 +23,19 @@ add_message "[subject]=\"json-show-utf8-body-s?bj?ct\""
"[date]=\"Sat, 01 Jan
output=$(notmuch show --format=json "js?n-show-m?ssage")
test_expect_equal "$output" "[[[{\"id\": \"${gen_msg_id}\", \"match\": true,
\"filename\": \"${gen_msg_filename}\", \"timestamp\": 946728000,
\"date_relative\": \"2000-01-01\", \"tags\": [\"inbox\",\"unread\"],
\"headers\": {\"Subject\": \"json-show-utf8-body-s?bj?ct\", \"From\": \"Notmuch
Test Suite \", \"To\": \"Notmuch Test Suite
\", \"Cc\": \"\", \"Bcc\": \"\", \"Date\":
\"Sat, 01 Jan 2000 12:00:00 -\"}, \"body\": [{\"id\": 1, \"content-type\":
\"text/plain\", \"content\": \"js?n-show-m?ssage\n\"}]}, ["
+test_begin_subtest "Show message: json, inline attachment filename"
+subject='json-show-inline-attachment-filename'
+id="json-show-inline-attachment-filename at notmuchmail.org"
+emacs_deliver_message \
+"$subject" \
+'This is a test message with inline attachment with a filename' \
+"(mml-attach-file \"$TEST_DIRECTORY/README\" nil nil \"inline\")
+ (message-goto-eoh)
+ (insert \"Message-ID: <$id>\n\")"
+output=$(notmuch show --format=json "id:$id")
+filename=$(notmuch search --output=files "id:$id")
+test_expect_equal "$output" "[[[{\"id\": \"$id\", \"match\": true,
\"filename\": \"$filename\", \"timestamp\": 946728000, \"date_relative\":
\"2000-01-01\", \"tags\": [\"inbox\"], \"headers\": {\"Subject\": \"$subject\",
\"From\": \"Notmuch Test Suite \", \"To\":
\"test_suite at notmuchmail.org\", \"Cc\": \"\", \"Bcc\": \"\", \"Date\": \"01
Jan 2000 12:00:00 -\"}, \"body\": [{\"id\": 1, \"content-type\":
\"multipart/mixed\", \"content\": [{\"id\": 2, \"content-type\":
\"text/plain\", \"content\": \"This is a test message with inline attachment
with a filename\"}, {\"id\": 3, \"content-type\": \"application/octet-stream\",
\"filename\": \"README\"}]}]}, ["
+
test_begin_subtest "Search message: json, utf-8"
add_message "[subject]=\"json-search-utf8-body-s?bj?ct\"" "[date]=\"Sat, 01
Jan 2000 12:00:00 -\"" "[body]=\"js?n-search-m?ssage\""
output=$(notmuch search --format=json "js?n-search-m?ssage" |
notmuch_search_sanitize)
--
1.7.5.4
[PATCH] NEWS: Add notes for (imminent) notmuch 0.6 release
By skimming through "git log 0.5..origin/release" late at night. Hopefully everything here is accurate. --- I've already pushed this out to master. David, obviously this is intended to be cherry-picked over to the release branch. And everyone, please review what I've written and provide any clarfications or corections necessary. Let me know if you think I've included more detail than necessary or if I've missed anything important. Thanks, -Carl NEWS | 344 ++ 1 files changed, 344 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index dae7832..d55453b 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,347 @@ +Notmuch 0.6 (2011-07-XX) +=== +New, general features +- +Folder-based searching + + Notmuch queries can now include a search term to match the + directories in which mail files are stored (within the mail + storage). The syntax is as follows: + + folder: + + For example, one might use things such as: + + folder:spam + folder:2011/06 + + or anything else that matches directories within your mail storage. + + This feature is particularly useful for users of delivery-agent + software (such as procmail or maildrop) that is filtering mail and + delivering it to particular folders, or users of systems such as + Gmail that use filesystem directories to indicate message tags. + + NOTE: Only messages that are newly indexed with this version of + notmuch will be searchable with folder: terms. In order to enable + this feature for all mail, the entire notmuch index will need to be + rebuilt as follows: + + notmuch dump > notmuch.dump + # Backup, then remove notmuch database ($MAIL/.notmuch) + notmuch new + notmuch restore notmuch.dump + +New, automatic tags: "signed" and "encrypted" + + These tags will automatically be applied to messages containing + multipart/signed and multipart/encrypted parts. + + NOTE: Only messages that are newly indexed with this version of + notmuch will receive these tags. In order to enable this feature for + all mail, the entire notmuch index will need to be rebuilt (see + above). + +New command-line features +- +Add new "notmuch show --verify" option for signature verification + + This option instruct notmuch to verify the signature of + PGP/MIME-signed parts. + +Add new "notmuch show --decrypt" and "notmuch reply --decrypt" options + + This option instructs notmuch to decrypt PGP/MIME-encrypted parts. + +Proper nesting of multipart parts in "notmuch show" output + + MIME parts are now display with proper nesting to reflect original + MIME hierarchy of a message. This allows clients to correctly + analyze the MIME structure, (such as, for example, determining to + which parts a signature part applies). + +Add new "notmuch show --part" option + + This is a replacement for the older "notmuch part" command, (which + is now deprecated?it should still work as always, but is no longer + documented). Putting part output under "notmuch show" allows for all + of the "notmuch show" options to be applied when extracting a single + part, (such as --format=json for extracting a message part with JSON + formatting). + +Deprecate "notmuch search-tags", (in favor of "notmuch search --output=tags *") + + The "notmuch search-tags" sub-command has been redundant since the + addition of the --output=tags option to "notmuch search". We now + make that more clear by deprecating "notmuch search-tags", (dropping + it from the documentation). We do continue to support the old syntax + by translating it internally to the new call. + +Performance improvements + +Faster searches (by doing fewer serches to construct threads) + + Whenever a user asks for search results as threads, notmuch first + performs a search for messages matching the query, then performs + additional searches to find other messages in the resulting threads. + + Removing inefficiences and redundancies in these secondary searches + results in a measured speedups of 1.5x for a typical search. + +Faster searches (by doing fewer passes to gather message data) + + Optimizing Xapian data access patterns (using a single pass to get + all message-document data rather than a ps for each data type) + results in a measured speedup of 1.7x for a typical search. + + The benefits of this optimization combine with the preceding + optimization. With both in place, Austin Clements measured a speedup + of 2.5x for a search of all messages in his inbox (was 4.5s, now + 1.8s). Thanks, Austin! + +Faster initial indexing + + More efficient indexing of new messages results in a measured + speedup of 1.4x for the initial indexing of 3 GB of mail (1h 14m + rather than 1h 46m). Thanks to Austin Clements and Michal Sojka. + +Make "notmuch new" faster for unchanged directories + + Optimizing to not do any further
[PATCH] emacs: Fix to unconditionally display subject changes in collapsed thread view
On Fri, 1 Jul 2011 02:01:08 -0700, Carl Worth wrote: > Rather than fixing the name of the variable and changing its default > value, here we remove the condition entirely, such that the feature is > enabled unconditionally. I've just pushed this change out. I emailed it here just to be able to comment on it. David, I implemented this fix while writing up the NEWS[*] notes for the 0.6 release (and noticing that this feature which was implemented wasn't actually usable as documented so I couldn't really add a NEWS item for it). If you want to sneak it into 0.6 I think it's safe, (it even hits one existing test case---though an additional test case to show an actual subject change appearing would be even better). It's your call of course, and if the change doesn't go, then that's fine too. In that case, I'll just not comment on this feature in NEWS until our next release. -Carl [*] Yes, I'm working away at this?almost done now... -- 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/20110701/8bb02d6b/attachment-0001.pgp>
[PATCH] emacs: Fix to unconditionally display subject changes in collapsed thread view
The feature to show subject changes in the collapsed thread view was originally added (8ab433607) with an option (notmuch-show-always-show-subject) to display the subject for all messages, even when there was no change. The subsequent commit (4f04d273) changed the sense of the test (or to and) and the name of the controlling variable (notmuch-show-elide-same-subject). But this commit is broken in a few ways: 1. The original definition of notmuch-show-always-show-subject was left around But the variable isn't actually used in the code at all, so it just adds clutter and confusion to the customization interface. 2. The name and description of the controlling variable doesn't match the implementation The name suggests that setting the variable to t will cause repeated subjects to be elided, (suggesting that when it is nil all subjects will be shown). However, when the variable is nil, no subjects are shown. So a correct name for the variable in this sense would be notmuch-show-subject-changes. Showing subject changes is a useful feature, and should be on by default. (We don't want to bury generally useful features behind customizations that users have to find). Rather than fixing the name of the variable and changing its default value, here we remove the condition entirely, such that the feature is enabled unconditionally. So both the currently-used variable and the stale definition of the formerly-used are removed. Also, the one relevant test-suite result is updated, (showing the intial subject of a collapsed thread, and no subject display for later messages that do not change the subject). --- emacs/notmuch-show.el | 16 ++-- .../notmuch-show-thread-with-hidden-messages |1 + 2 files changed, 3 insertions(+), 14 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 6685717..f96743b 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -65,17 +65,6 @@ any given message." :group 'notmuch :type 'boolean) -(defcustom notmuch-show-elide-same-subject nil - "Do not show the subject of a collapsed message if it is the -same as that of the previous message." - :group 'notmuch - :type 'boolean) - -(defcustom notmuch-show-always-show-subject t - "Should a collapsed message show the `Subject:' line?" - :group 'notmuch - :type 'boolean) - (defvar notmuch-show-markup-headers-hook '(notmuch-show-colour-headers) "A list of functions called to decorate the headers listed in `notmuch-message-headers'.") @@ -727,9 +716,8 @@ current buffer, if possible." ;; If the subject of this message is the same as that of the ;; previous message, don't display it when this message is ;; collapsed. - (when (and notmuch-show-elide-same-subject -(not (string= notmuch-show-previous-subject - bare-subject))) + (when (not (string= notmuch-show-previous-subject + bare-subject)) (forward-line 1)) (setq headers-start (point-marker))) (setq headers-end (point-marker)) diff --git a/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages b/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages index 5df6606..8a0660f 100644 --- a/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages +++ b/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages @@ -1,3 +1,4 @@ Jan Janak (2009-11-17) (inbox unread) +Subject: [notmuch] What a great idea! Jan Janak (2009-11-17) (inbox) Carl Worth (2009-11-18) (inbox unread) -- 1.7.5.4
Re: Notmuch 0.6: Let's do it.
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. pgpi2PChSVQ0e.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] test: add/remove tags from all matching messages with `notmuch-search-operate-all'
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 pie...@praet.org --- 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@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 EOF EXPECTED + 2009-11-18 [3/3] Adrian Perez de Castro, Keith Packard, Carl Worth [notmuch] Introducing myself (matching signed unread) + 2009-11-18 [1/3] Carl Worth, Israel Herraiz, Keith Packard [notmuch] New to the list (inbox matching unread) + 2009-11-18 [2/2] Keith Packard, Carl Worth[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags (matching unread) + 2009-11-18 [1/2] Keith Packard, Alexander Botero-Lowry[notmuch] [PATCH] Create a default notmuch-show-hook that highlights URLs and uses word-wrap (inbox matching unread) + 2009-11-18 [1/1] Jan Janak[notmuch] [PATCH] notmuch new: Support for conversion of spool subdirectories into tags (matching unread) + 2009-11-18 [1/1] Stewart Smith[notmuch] [PATCH] Fix linking with gcc to use g++ to link in C++ libs. (matching unread) + 2009-11-17 [1/2] Ingmar Vanhassel, Carl Worth [notmuch] [PATCH] Typsos (inbox matching unread) +End of search results. +EOF +test_expect_equal_file OUTPUT EXPECTED + test_done -- 1.7.4.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove prefixes from `--output={threads, messages}' results
On Thu, 30 Jun 2011 09:24:12 -0700, Carl Worth cwo...@cworth.org wrote: Non-text part: multipart/signed On Thu, 30 Jun 2011 10:19:49 +0200, Pieter Praet pie...@praet.org 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-pie...@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.wo...@intel.com Non-text part: application/pgp-signature Peace -- Pieter [1] id:1309422029-22924-1-git-send-email-pie...@praet.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] [RFC] possible solution for Race condition for '*' command
On Thu, 30 Jun 2011 18:08:28 +0200, Pieter Praet pie...@praet.org 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@dragonfly.greenrd.org Signed-off-by: Pieter Praet pie...@praet.org --- 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@praet.org [2] id:1309450108-2793-2-git-send-email-pie...@praet.org [3] id:1309450108-2793-1-git-send-email-pie...@praet.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Preventing the user shooting themself in the foot
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 not sure why notmuch reply is putting that there :) 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. I'm come to strongly agree that this is the Right Way to process email too, so should there be a keybinding for this last operation? It should tag the message (or the thread?) with, say, 'task', and then proceeded as 'a' does. 'task' should be in the default searches you get in the notmuch hello buffer. I realize there is endless bikeshedding to be done on tag names and so on and also on allowing people to choose their own workflow, but I also think that this shouldn't stop the addition of a sensible default :) Cheers, mwh ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Preventing the user shooting themself in the foot
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@cworth.org wrote: 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. IMHO this is one of the awesome things about notmuch (and I've actively used it to go back on conversations I previously ignored) -- Stewart Smith ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Preventing the user shooting themself in the foot
On 30 June 2011 17:50, Pieter Praet pie...@praet.org wrote: And AFAIK, Archive does *not* mark a message as read in GMail. (see previous messages suggesting the inverse) gmail will mark all messages in the thread as read when looking at any part of the thread - so in practical terms whenever I click Archive the entire thread is marked as read - as I always click archive in the message view. Not absolutely convinced this is the best approach. I think it is important to appreciate the differences that different implementations have chosen. -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: json show format of message with inline attachment with filename
The patch adds a test to check that json show format includes
filenames for attachments with inline disposition.
---
Carl, I owe you this test case for my patch that added filenames
for inline attachments :)
Regards,
Dmitry
test/json | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/test/json b/test/json
index 5a2544c..592b068 100755
--- a/test/json
+++ b/test/json
@@ -23,6 +23,19 @@ add_message [subject]=\json-show-utf8-body-sübjéct\
[date]=\Sat, 01 Jan
output=$(notmuch show --format=json jsön-show-méssage)
test_expect_equal $output [[[{\id\: \${gen_msg_id}\, \match\: true,
\filename\: \${gen_msg_filename}\, \timestamp\: 946728000,
\date_relative\: \2000-01-01\, \tags\: [\inbox\,\unread\],
\headers\: {\Subject\: \json-show-utf8-body-sübjéct\, \From\: \Notmuch
Test Suite test_su...@notmuchmail.org\, \To\: \Notmuch Test Suite
test_su...@notmuchmail.org\, \Cc\: \\, \Bcc\: \\, \Date\: \Sat,
01 Jan 2000 12:00:00 -\}, \body\: [{\id\: 1, \content-type\:
\text/plain\, \content\: \jsön-show-méssage\n\}]}, [
+test_begin_subtest Show message: json, inline attachment filename
+subject='json-show-inline-attachment-filename'
+id=json-show-inline-attachment-filen...@notmuchmail.org
+emacs_deliver_message \
+$subject \
+'This is a test message with inline attachment with a filename' \
+(mml-attach-file \$TEST_DIRECTORY/README\ nil nil \inline\)
+ (message-goto-eoh)
+ (insert \Message-ID: $id\n\)
+output=$(notmuch show --format=json id:$id)
+filename=$(notmuch search --output=files id:$id)
+test_expect_equal $output [[[{\id\: \$id\, \match\: true,
\filename\: \$filename\, \timestamp\: 946728000, \date_relative\:
\2000-01-01\, \tags\: [\inbox\], \headers\: {\Subject\: \$subject\,
\From\: \Notmuch Test Suite test_su...@notmuchmail.org\, \To\:
\test_su...@notmuchmail.org\, \Cc\: \\, \Bcc\: \\, \Date\: \01 Jan
2000 12:00:00 -\}, \body\: [{\id\: 1, \content-type\:
\multipart/mixed\, \content\: [{\id\: 2, \content-type\:
\text/plain\, \content\: \This is a test message with inline attachment
with a filename\}, {\id\: 3, \content-type\: \application/octet-stream\,
\filename\: \README\}]}]}, [
+
test_begin_subtest Search message: json, utf-8
add_message [subject]=\json-search-utf8-body-sübjéct\ [date]=\Sat, 01
Jan 2000 12:00:00 -\ [body]=\jsön-search-méssage\
output=$(notmuch search --format=json jsön-search-méssage |
notmuch_search_sanitize)
--
1.7.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: do not hide test_emacs errors
Do not redirect test_emacs stderr to /dev/null. Test_emacs uses
emacsclient(1) now and it does not print unwanted messages (like
those from `message') to stderr. But it does print useful
errors, e.g. when emacs server connection fails, given expression
is not valid or undefined function is called.
---
test/emacs |4 ++--
test/test-lib.sh |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/test/emacs b/test/emacs
index 53f455a..dbe8d9e 100755
--- a/test/emacs
+++ b/test/emacs
@@ -261,13 +261,13 @@ test_begin_subtest Save attachment from within emacs
using notmuch-show-save-at
# save as archive to test that Emacs does not re-compress .gz
test_emacs '(let ((standard-input \attachment1.gz\))
(notmuch-show
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com)
- (notmuch-show-save-attachments))' /dev/null 21
+ (notmuch-show-save-attachments))'
test_expect_equal_file attachment1.gz $EXPECTED/attachment
test_begin_subtest Save attachment from within emacs using
notmuch-show-save-part
# save as archive to test that Emacs does not re-compress .gz
test_emacs '(let ((standard-input \attachment2.gz\))
- (notmuch-show-save-part
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com 5))'
/dev/null 21
+ (notmuch-show-save-part
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com 5))'
test_expect_equal_file attachment2.gz $EXPECTED/attachment
test_begin_subtest View raw message within emacs
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 22e387e..37f007a 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -394,7 +394,7 @@ emacs_deliver_message ()
(message-goto-body)
(insert \${body}\)
$@
- (message-send-and-exit)) /dev/null 21
+ (message-send-and-exit))
wait ${smtp_dummy_pid}
notmuch new /dev/null
}
--
1.7.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 0/7] advance-and-archive bugfix, run emacs inside screen
Amended patch series. Only minor changes: * redirect errors from test_emacs in the emacs server wait loop to /dev/null * reordered patches Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 5/7] emacs: improve hidden signatures handling in notmuch-show-advance-and-archive
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 6/7] emacs: remove no longer used functions from notmuch-show.el
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 7/7] emacs: remove unused `point-invisible-p' function
`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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Fix to unconditionally display subject changes in collapsed thread view
The feature to show subject changes in the collapsed thread view was originally added (8ab433607) with an option (notmuch-show-always-show-subject) to display the subject for all messages, even when there was no change. The subsequent commit (4f04d273) changed the sense of the test (or to and) and the name of the controlling variable (notmuch-show-elide-same-subject). But this commit is broken in a few ways: 1. The original definition of notmuch-show-always-show-subject was left around But the variable isn't actually used in the code at all, so it just adds clutter and confusion to the customization interface. 2. The name and description of the controlling variable doesn't match the implementation The name suggests that setting the variable to t will cause repeated subjects to be elided, (suggesting that when it is nil all subjects will be shown). However, when the variable is nil, no subjects are shown. So a correct name for the variable in this sense would be notmuch-show-subject-changes. Showing subject changes is a useful feature, and should be on by default. (We don't want to bury generally useful features behind customizations that users have to find). Rather than fixing the name of the variable and changing its default value, here we remove the condition entirely, such that the feature is enabled unconditionally. So both the currently-used variable and the stale definition of the formerly-used are removed. Also, the one relevant test-suite result is updated, (showing the intial subject of a collapsed thread, and no subject display for later messages that do not change the subject). --- emacs/notmuch-show.el | 16 ++-- .../notmuch-show-thread-with-hidden-messages |1 + 2 files changed, 3 insertions(+), 14 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 6685717..f96743b 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -65,17 +65,6 @@ any given message. :group 'notmuch :type 'boolean) -(defcustom notmuch-show-elide-same-subject nil - Do not show the subject of a collapsed message if it is the -same as that of the previous message. - :group 'notmuch - :type 'boolean) - -(defcustom notmuch-show-always-show-subject t - Should a collapsed message show the `Subject:' line? - :group 'notmuch - :type 'boolean) - (defvar notmuch-show-markup-headers-hook '(notmuch-show-colour-headers) A list of functions called to decorate the headers listed in `notmuch-message-headers'.) @@ -727,9 +716,8 @@ current buffer, if possible. ;; If the subject of this message is the same as that of the ;; previous message, don't display it when this message is ;; collapsed. - (when (and notmuch-show-elide-same-subject -(not (string= notmuch-show-previous-subject - bare-subject))) + (when (not (string= notmuch-show-previous-subject + bare-subject)) (forward-line 1)) (setq headers-start (point-marker))) (setq headers-end (point-marker)) diff --git a/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages b/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages index 5df6606..8a0660f 100644 --- a/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages +++ b/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages @@ -1,3 +1,4 @@ Jan Janak j...@ryngle.com (2009-11-17) (inbox unread) +Subject: [notmuch] What a great idea! Jan Janak j...@ryngle.com (2009-11-17) (inbox) Carl Worth cwo...@cworth.org (2009-11-18) (inbox unread) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Fix to unconditionally display subject changes in collapsed thread view
On Fri, 1 Jul 2011 02:01:08 -0700, Carl Worth cwo...@cworth.org wrote: Rather than fixing the name of the variable and changing its default value, here we remove the condition entirely, such that the feature is enabled unconditionally. I've just pushed this change out. I emailed it here just to be able to comment on it. David, I implemented this fix while writing up the NEWS[*] notes for the 0.6 release (and noticing that this feature which was implemented wasn't actually usable as documented so I couldn't really add a NEWS item for it). If you want to sneak it into 0.6 I think it's safe, (it even hits one existing test case---though an additional test case to show an actual subject change appearing would be even better). It's your call of course, and if the change doesn't go, then that's fine too. In that case, I'll just not comment on this feature in NEWS until our next release. -Carl [*] Yes, I'm working away at this—almost done now... pgpXiFxJ4yJoe.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] NEWS: Add notes for (imminent) notmuch 0.6 release
By skimming through git log 0.5..origin/release late at night. Hopefully everything here is accurate. --- I've already pushed this out to master. David, obviously this is intended to be cherry-picked over to the release branch. And everyone, please review what I've written and provide any clarfications or corections necessary. Let me know if you think I've included more detail than necessary or if I've missed anything important. Thanks, -Carl NEWS | 344 ++ 1 files changed, 344 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index dae7832..d55453b 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,347 @@ +Notmuch 0.6 (2011-07-XX) +=== +New, general features +- +Folder-based searching + + Notmuch queries can now include a search term to match the + directories in which mail files are stored (within the mail + storage). The syntax is as follows: + + folder:path + + For example, one might use things such as: + + folder:spam + folder:2011/06 + + or anything else that matches directories within your mail storage. + + This feature is particularly useful for users of delivery-agent + software (such as procmail or maildrop) that is filtering mail and + delivering it to particular folders, or users of systems such as + Gmail that use filesystem directories to indicate message tags. + + NOTE: Only messages that are newly indexed with this version of + notmuch will be searchable with folder: terms. In order to enable + this feature for all mail, the entire notmuch index will need to be + rebuilt as follows: + + notmuch dump notmuch.dump + # Backup, then remove notmuch database ($MAIL/.notmuch) + notmuch new + notmuch restore notmuch.dump + +New, automatic tags: signed and encrypted + + These tags will automatically be applied to messages containing + multipart/signed and multipart/encrypted parts. + + NOTE: Only messages that are newly indexed with this version of + notmuch will receive these tags. In order to enable this feature for + all mail, the entire notmuch index will need to be rebuilt (see + above). + +New command-line features +- +Add new notmuch show --verify option for signature verification + + This option instruct notmuch to verify the signature of + PGP/MIME-signed parts. + +Add new notmuch show --decrypt and notmuch reply --decrypt options + + This option instructs notmuch to decrypt PGP/MIME-encrypted parts. + +Proper nesting of multipart parts in notmuch show output + + MIME parts are now display with proper nesting to reflect original + MIME hierarchy of a message. This allows clients to correctly + analyze the MIME structure, (such as, for example, determining to + which parts a signature part applies). + +Add new notmuch show --part option + + This is a replacement for the older notmuch part command, (which + is now deprecated—it should still work as always, but is no longer + documented). Putting part output under notmuch show allows for all + of the notmuch show options to be applied when extracting a single + part, (such as --format=json for extracting a message part with JSON + formatting). + +Deprecate notmuch search-tags, (in favor of notmuch search --output=tags *) + + The notmuch search-tags sub-command has been redundant since the + addition of the --output=tags option to notmuch search. We now + make that more clear by deprecating notmuch search-tags, (dropping + it from the documentation). We do continue to support the old syntax + by translating it internally to the new call. + +Performance improvements + +Faster searches (by doing fewer serches to construct threads) + + Whenever a user asks for search results as threads, notmuch first + performs a search for messages matching the query, then performs + additional searches to find other messages in the resulting threads. + + Removing inefficiences and redundancies in these secondary searches + results in a measured speedups of 1.5x for a typical search. + +Faster searches (by doing fewer passes to gather message data) + + Optimizing Xapian data access patterns (using a single pass to get + all message-document data rather than a ps for each data type) + results in a measured speedup of 1.7x for a typical search. + + The benefits of this optimization combine with the preceding + optimization. With both in place, Austin Clements measured a speedup + of 2.5x for a search of all messages in his inbox (was 4.5s, now + 1.8s). Thanks, Austin! + +Faster initial indexing + + More efficient indexing of new messages results in a measured + speedup of 1.4x for the initial indexing of 3 GB of mail (1h 14m + rather than 1h 46m). Thanks to Austin Clements and Michal Sojka. + +Make notmuch new faster for unchanged directories + + Optimizing to not do any further examinations of sub-directories +
[PATCH 2/2] [RFC] possible solution for Race condition for '*' command
`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@dragonfly.greenrd.org Signed-off-by: Pieter Praet pie...@praet.org --- 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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove prefixes from `--output={threads, messages}' results
On Thu, 30 Jun 2011 10:19:49 +0200, Pieter Praet pie...@praet.org 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-pie...@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.wo...@intel.com pgpidP7oSWd6S.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: patchwork
On Thu, 30 Jun 2011 11:01:14 +0200, martin f krafft madd...@madduck.net 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.wo...@intel.com pgpnDhMlqesfi.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 1/7] test: run emacs inside screen
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 22e387e..688598c 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -858,10 +858,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 '()' 2/dev/null; do
+ sleep 1
+ done
fi
emacsclient --socket-name=$EMACS_SERVER --eval (progn $@)
--
1.7.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 3/7] test: do not set frame width in emacs
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 dmitry.kuroch...@gmail.com -;; 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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 4/7] test: `notmuch-show-advance-and-archive' with invisible signature
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 53f455a..708c504 100755 --- a/test/emacs +++ b/test/emacs @@ -347,4 +347,18 @@ 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 'notmuch-show-advance-and-archive with invisible signature' +message1='id:20091118010116.gc25...@dottiness.seas.harvard.edu' +message2='id:1258491078-29658-1-git-send-email-dotted...@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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Gnus (nnml) + notmuch
Hi. Has anyone integrated Gnus (with nnml: groups) and notmuch (for instance using the org-gnus-follow-link way described by Tassilo Horn [0] ? I'm concerned with automatically tagging mails split in groups by nnmail-split-methods with their group names, handling read/unread marks (and more), and of course reading/responding to mails in the most straightforward way with Gnus modes. Many thanks in advance. Best regards, [0] http://article.gmane.org/gmane.emacs.gnus.user/13308 -- Olivier BERGER (OpenPGP: 4096R/7C5BB6A5) http://www.olivierberger.com/weblog/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] [RFC] possible solution for Race condition for '*' command
On Jul 1, 2011 10:55 AM, Austin Clements amdra...@mit.edu wrote: On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet pie...@praet.org wrote: 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@praet.org [2] id:1309450108-2793-2-git-send-email-pie...@praet.org [3] id:1309450108-2793-1-git-send-email-pie...@praet.org Ideally, this wouldn't be per-buffer, but per *line*. This race equally affects adding and removing tags from individual results, since that's done using a thread: query, whose results could have changed since the original search. This almost certainly requires support from the notmuch core. The good news is that the library already provides this information, so there will be virtually no performance hit for outputting it. Actually, with a smidgeon of library support, you could even use document IDs for this, rather than message IDs, which would make the tagging operations (even '*') no more expensive than they are now. (Of course, it would be good to know just how much overhead going through message IDs actually introduces.) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Preventing the user shooting themself in the foot
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle michael.hud...@canonical.com wrote: 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 not sure why notmuch reply is putting that there :) They shouldn't be, and I sent a patch to fix that a while ago: id:1307561409-5646-3-git-send-email-jroll...@finestructure.net But of course feel free to delete them before sending. I'm come to strongly agree that this is the Right Way to process email too, so should there be a keybinding for this last operation? It should tag the message (or the thread?) with, say, 'task', and then proceeded as 'a' does. 'task' should be in the default searches you get in the notmuch hello buffer. While I agree that Carl's method is pretty good, there is absolutely no Right Way to process email; it's a completely personal, subjective thing. Right Way implies to me that other people *should* be processing their mail that way, which I disagree with. I'm generally against excessive unneeded configuration, but in the case of key bindings it's definitely necessary. Fortunately emacs is so fundamentally flexible one can always modify the keybindings to their hearts content. jamie. pgppxGRgcBa3H.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
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle michael.hud...@canonical.com wrote: 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 not sure why notmuch reply is putting that there :) 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. I'm come to strongly agree that this is the Right Way to process email too, so should there be a keybinding for this last operation? It should tag the message (or the thread?) with, say, 'task', and then proceeded as 'a' does. 'task' should be in the default searches you get in the notmuch hello buffer. #+BEGIN_SRC emacs-lisp (define-key notmuch-show-mode-map t (lambda() Flag and archive currently selected message, and move to the next. If this is the last message, move to the next thread. (interactive) (notmuch-show-add-tag flagged) (notmuch-show-advance-and-archive))) #+END_SRC Note that I use the flagged tag, since this corresponds to a maildir flag, and can be synced via IMAP. I realize there is endless bikeshedding to be done on tag names and so on and also on allowing people to choose their own workflow, but I also think that this shouldn't stop the addition of a sensible default :) Cheers, mwh ___ 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: Preventing the user shooting themself in the foot
On Fri, Jul 1, 2011 at 12:37 PM, Jameson Graef Rollins jroll...@finestructure.net wrote: On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle michael.hud...@canonical.com wrote: On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@cworth.org wrote: I'm come to strongly agree that this is the Right Way to process email too, so should there be a keybinding for this last operation? It should tag the message (or the thread?) with, say, 'task', and then proceeded as 'a' does. 'task' should be in the default searches you get in the notmuch hello buffer. While I agree that Carl's method is pretty good, there is absolutely no Right Way to process email; it's a completely personal, subjective thing. Right Way implies to me that other people *should* be processing their mail that way, which I disagree with. I'm generally against excessive unneeded configuration, but in the case of key bindings it's definitely necessary. Fortunately emacs is so fundamentally flexible one can always modify the keybindings to their hearts content. While that's true and opens endless possibilities for power users, the defaults need to be suited to new users. Nobody wants to use a tool that takes endless configuration just to get started, especially since that's when you least know what configuration you want. Simple bindings with predictable behaviors that allow users to express their own workflow, even if it requires a few more keystrokes, make better defaults than bindings that codify a particular workflow. As users become more adept at a tool, this enables them to *incrementally* capture (and refine) their workflow as more optimized bindings. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] NEWS: spellcheck notes for notmuch 0.6 resease
Just fix some typos in the recently added NEWS for notmuch 0.6 release. --- NEWS | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/NEWS b/NEWS index d55453b..d9ffb02 100644 --- a/NEWS +++ b/NEWS @@ -79,13 +79,13 @@ Deprecate notmuch search-tags, (in favor of notmuch search --output=tags *) Performance improvements -Faster searches (by doing fewer serches to construct threads) +Faster searches (by doing fewer searches to construct threads) Whenever a user asks for search results as threads, notmuch first performs a search for messages matching the query, then performs additional searches to find other messages in the resulting threads. - Removing inefficiences and redundancies in these secondary searches + Removing inefficiencies and redundancies in these secondary searches results in a measured speedups of 1.5x for a typical search. Faster searches (by doing fewer passes to gather message data) @@ -130,7 +130,7 @@ User-selectable From address will prompt for the from address to use. The user can customize the Notmuch Identities setting in the - notmuch cutomize group in order to use addresses other than those in + notmuch customize group in order to use addresses other than those in the notmuch configuration file if desired. The user can also choose to always be prompted for the from address @@ -154,7 +154,7 @@ New hooks for running code when tags are modified Some users want to perform additional actions whenever a particular tag is added/removed from a message. This could be used to, for example, interface with some external spam-recognition training - tool. T facilitate this, two new hooks are added which can be + tool. To facilitate this, two new hooks are added which can be modified in the following settings of the notmuch customize group: Notmuch Before Tag Hook @@ -181,7 +181,7 @@ Better rendering of text/x-vcalendar parts Avoid getting confused by Subject and Author fields with newline characters - Replacing all characters with ACII code less than 32 with a question mark. + Replacing all characters with ASCII code less than 32 with a question mark. Cleaner display of From line in email messages (remove double quotes, and drop name if it's actually just a repeat of the email address). @@ -254,17 +254,17 @@ Binary for bash for running test suite now located via PATH. bash 4). As some systems supply an older version of bash at /bin/bash, the test suite is now updated to search $PATH to locate the bash binary. This allows users of systems with old /bin/bash to - simply install bash = 4 somwhere on $PATH before /bin and then use + simply install bash = 4 somewhere on $PATH before /bin and then use the test suite. Support for testing output with a trailing newline. Previously, some tests would fail to notice a difference in the - presense/absence of a trailing newline in a program output, (which + presence/absence of a trailing newline in a program output, (which has led to bugs in the past). Now, carefully-written tests (using test_expect_equal_file rather than test_expect_equal) will detect any change in the presence/absence of a trailing newline. Many tests - are updated to take advnatage of this. + are updated to take advantage of this. Avoiding accessing user's $HOME while running test suite @@ -313,7 +313,7 @@ Fix libnotmuch library to only export notmuch API functions Previous release of the notmuch library also exported some Xapian C++ exception type symbols. These were never part of the library - interface and were never intented to be exported. + interface and were never intended to be exported. Emacs-interface bug fixes - @@ -321,16 +321,16 @@ Display any unexpected output or errors from notmuch search invocations Previously any misformatted output or trailing error messages were silently ignored. This output is now clearly displayed. This fix was - very helpful in identifying and fixing the bug decribed below. + very helpful in identifying and fixing the bug described below. Fix bug where some threads would be missing from large search results When a search returned a large number of results, the emacs - interface was incorrectly dropping one thread everytime the output - of the notmuch search process spanned the emacss read-buffer. This + interface was incorrectly dropping one thread every time the output + of the notmuch search process spanned the emacs read-buffer. This is now fixed. -Avoid rec-compression of .gz files (and similar) when saving attachment +Avoid re-compression of .gz files (and similar) when saving attachment Emacs was being too clever for its own good and trying to re-compress pre-compressed .gz files when saving such attachments -- 1.7.5.4 ___ notmuch mailing
[PATCH v2] NEWS: spellcheck notes for notmuch 0.6 resease
Just fix some typos in the recently added NEWS for notmuch 0.6 release. --- Amended version, fixes one more typo. Regards, Dmitry NEWS | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/NEWS b/NEWS index d55453b..8149899 100644 --- a/NEWS +++ b/NEWS @@ -79,19 +79,19 @@ Deprecate notmuch search-tags, (in favor of notmuch search --output=tags *) Performance improvements -Faster searches (by doing fewer serches to construct threads) +Faster searches (by doing fewer searches to construct threads) Whenever a user asks for search results as threads, notmuch first performs a search for messages matching the query, then performs additional searches to find other messages in the resulting threads. - Removing inefficiences and redundancies in these secondary searches + Removing inefficiencies and redundancies in these secondary searches results in a measured speedups of 1.5x for a typical search. Faster searches (by doing fewer passes to gather message data) Optimizing Xapian data access patterns (using a single pass to get - all message-document data rather than a ps for each data type) + all message-document data rather than a pass for each data type) results in a measured speedup of 1.7x for a typical search. The benefits of this optimization combine with the preceding @@ -130,7 +130,7 @@ User-selectable From address will prompt for the from address to use. The user can customize the Notmuch Identities setting in the - notmuch cutomize group in order to use addresses other than those in + notmuch customize group in order to use addresses other than those in the notmuch configuration file if desired. The user can also choose to always be prompted for the from address @@ -154,7 +154,7 @@ New hooks for running code when tags are modified Some users want to perform additional actions whenever a particular tag is added/removed from a message. This could be used to, for example, interface with some external spam-recognition training - tool. T facilitate this, two new hooks are added which can be + tool. To facilitate this, two new hooks are added which can be modified in the following settings of the notmuch customize group: Notmuch Before Tag Hook @@ -181,7 +181,7 @@ Better rendering of text/x-vcalendar parts Avoid getting confused by Subject and Author fields with newline characters - Replacing all characters with ACII code less than 32 with a question mark. + Replacing all characters with ASCII code less than 32 with a question mark. Cleaner display of From line in email messages (remove double quotes, and drop name if it's actually just a repeat of the email address). @@ -254,17 +254,17 @@ Binary for bash for running test suite now located via PATH. bash 4). As some systems supply an older version of bash at /bin/bash, the test suite is now updated to search $PATH to locate the bash binary. This allows users of systems with old /bin/bash to - simply install bash = 4 somwhere on $PATH before /bin and then use + simply install bash = 4 somewhere on $PATH before /bin and then use the test suite. Support for testing output with a trailing newline. Previously, some tests would fail to notice a difference in the - presense/absence of a trailing newline in a program output, (which + presence/absence of a trailing newline in a program output, (which has led to bugs in the past). Now, carefully-written tests (using test_expect_equal_file rather than test_expect_equal) will detect any change in the presence/absence of a trailing newline. Many tests - are updated to take advnatage of this. + are updated to take advantage of this. Avoiding accessing user's $HOME while running test suite @@ -313,7 +313,7 @@ Fix libnotmuch library to only export notmuch API functions Previous release of the notmuch library also exported some Xapian C++ exception type symbols. These were never part of the library - interface and were never intented to be exported. + interface and were never intended to be exported. Emacs-interface bug fixes - @@ -321,16 +321,16 @@ Display any unexpected output or errors from notmuch search invocations Previously any misformatted output or trailing error messages were silently ignored. This output is now clearly displayed. This fix was - very helpful in identifying and fixing the bug decribed below. + very helpful in identifying and fixing the bug described below. Fix bug where some threads would be missing from large search results When a search returned a large number of results, the emacs - interface was incorrectly dropping one thread everytime the output - of the notmuch search process spanned the emacss read-buffer. This + interface was incorrectly dropping one thread every time the output + of the notmuch search process spanned the
Possible bug: wrong from address when forwarding
Hi I am seeing the following bug in the emacs interface: when I forward a message (f when showing a message) I get a message with the from address filled in by the host operating system (walters@hostname) rather than my notmuch configured address. If I compose mail normally notmuch fills in the correct (notmuch configured) address. The problem could be in my setup but as far as I can see in notmuch-mua.el notmuch-mua-forward-message and notmuch-mua-mail behave differently: the latter fills in the from header with notmuch-user-primary-email and the former does not. Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
problem with message/rfc822 parts
today I updated to the latest git version of notmuch, which mostly works as expected. However, I now have the problem that whenever I look via emacs interface at a message which contains an embedded message/rfc822 part (like a forwarded message), then I just see [ message/rfc822 ] in the display buffer. I would expect that I am somehow able to access/view the forwarded message from the emacs interface, however I do not know how to achieve this. This worked fine with notmuch versions from April, but somehow it seems to be broken now for me. Is this a known problem or do I need some configuration magic? Any hints for debugging this would be welcome. Andreas ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
branchs and tags and merges oh my!
Much to everyone's relief, 0.6 is finally released. From a git perspective, the release process went like this. 0) I branched release from master on June 22 1) I cherry-picked some subset of post June 22 commits from master to release 1a) actually I cheated and cherry-picked the last few commits back from release to master. I don't _think_ this matters. 2) I tagged and uploaded from branch release -.-- master \ --release 0.6 So now we have to decide what to do. FWIW, there are about 20 commits on release past d6f05fd. There are two obvious strategies going forward. 1) repeat the whole thing with a new release branch for 0.7 and end up with --.--.--- master \ \ - 0.6 --- 0.7 2) merge master onto the release branch ---..- master \\ / -.. 0.7 0.6 now freeze I personally think having git log 0.6..0.7 do something sensible is worth a lot, but this option does in some sense make the history of master messier (some commits occur twice with different sha1's). Discussion? d pgpStOaTOFAi0.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
On Fri, 1 Jul 2011 11:28:10 +1000, Brian May br...@microcomaustralia.com.au wrote: On 30 June 2011 17:50, Pieter Praet pie...@praet.org wrote: And AFAIK, Archive does *not* mark a message as read in GMail. (see previous messages suggesting the inverse) gmail will mark all messages in the thread as read when looking at any part of the thread - so in practical terms whenever I click Archive the entire thread is marked as read - as I always click archive in the message view. Not absolutely convinced this is the best approach. I think it is important to appreciate the differences that different implementations have chosen. I was thinking more along the lines of archiving a message from the Inbox (or similar) view, in which the 'unread' state does remain preserved. Marking all messages as read as soon as the thread is opened is a separate issue (and *far* from sensible), but this heavy-handed approach is probably a necessity (as opposed to being a deliberate choice) due to the limitations of its current interface, which Notmuch thankfully doesn't share. -- Brian May br...@microcomaustralia.com.au ___ 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: problem with message/rfc822 parts
It's a known problem. As a short term fix, try the patches of id:1307320169-29905-1-git-send-email-jroll...@finestructure.net thanks a lot David. I can confirm that it works for me. Andreas ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
