Possible bug: wrong from address when forwarding
--- Either enable `notmuch-always-prompt-for-sender', or apply this quick-fix patch, which uses `name' and `primary_email' as configured in your .notmuch-config if aforementioned isn't enabled. emacs/notmuch-mua.el |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 274c5da..27c6884 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -213,7 +213,9 @@ the From: address first." (user-full-name (car address-components)) (user-mail-address (cadr address-components))) (notmuch-mua-forward-message)) -(notmuch-mua-forward-message))) +(let* ((user-full-name (notmuch-user-name)) + (user-mail-address (notmuch-user-primary-email))) +(notmuch-mua-forward-message (defun notmuch-mua-new-reply (query-string prompt-for-sender) "Invoke the notmuch reply window." -- 1.7.5.4
problem with message/rfc822 parts
On Sat, 02 Jul 2011 02:23:34 +0100, Andreas Amann wrote: > > 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" > > Or use `notmuch-show-view-raw-message' (bound to 'V'). > thanks a lot David. I can confirm that it works for me. > > Andreas > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter
[PATCH 2/2] [RFC] possible solution for "Race condition for '*' command"
On Fri, 1 Jul 2011 12:37:11 -0400, Austin Clements wrote: Non-text part: multipart/alternative > 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.) Non-text part: text/html That would be awesome! Though I'd rather leave the plumbing to someone sufficiently capable, so, if leaving libnotmuch hacking out of the equation, how would one go about doing this? I (ignorantly) assume we'd get `notmuch-search-process-filter' to append each line with an invisible field containing a list of matching Message-Id's, presumably obtained via `notmuch_thread_get_matched_messages' (@ lib/thread.cc) ? Peace -- Pieter
[PATCH 2/2] emacs: Tests for user-defined sections
--- test/emacs | 37 test/emacs.expected-output/notmuch-hello |3 +- .../notmuch-hello-new-section |4 ++ .../notmuch-hello-no-saved-searches|3 +- .../notmuch-hello-section-before | 18 + .../notmuch-hello-section-counts |5 +++ .../notmuch-hello-section-hidden-tag |4 ++ .../notmuch-hello-section-with-empty |4 ++ .../emacs.expected-output/notmuch-hello-with-empty |3 +- 9 files changed, 78 insertions(+), 3 deletions(-) create mode 100644 test/emacs.expected-output/notmuch-hello-new-section create mode 100644 test/emacs.expected-output/notmuch-hello-section-before create mode 100644 test/emacs.expected-output/notmuch-hello-section-counts create mode 100644 test/emacs.expected-output/notmuch-hello-section-hidden-tag create mode 100644 test/emacs.expected-output/notmuch-hello-section-with-empty diff --git a/test/emacs b/test/emacs index 53f455a..e5ae509 100755 --- a/test/emacs +++ b/test/emacs @@ -34,6 +34,43 @@ test_emacs '(let ((notmuch-saved-searches (test-output))' test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-no-saved-searches +test_begin_subtest "User defined section with inbox tag" +test_emacs "(let ((notmuch-hello-sections + (list (lambda () (notmuch-hello-insert-query-list + \"Test: \" '((\"inbox\" . \"tag:inbox\"))) + (notmuch-hello) + (test-output))" +test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-new-section + +test_begin_subtest "User defined section with empty, hidden entry" +test_emacs "(let ((notmuch-hello-sections + (list (lambda () (notmuch-hello-insert-query-list + \"Test-with-empty:\" + '((\"inbox\" . \"tag:inbox\") + (\"doesnotexist\" . \"tag:doesnotexist\")) + :hide-empty-tags t) + (notmuch-hello) + (test-output))" +test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-with-empty + +test_begin_subtest "User defined section, unread tag filtered out" +test_emacs "(let ((notmuch-hello-sections + (list (lambda () (notmuch-hello-insert-tags-section + :title \"Test-with-filtered: \" + :hide-tags '(\"unread\")) + (notmuch-hello) + (test-output))" +test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-hidden-tag + +test_begin_subtest "User defined section, different query for counts" +test_emacs "(let ((notmuch-hello-sections + (list (lambda () (notmuch-hello-insert-tags-section + :title \"Test-with-counts: \" + :make-count \"tag:signed\") + (notmuch-hello) + (test-output))" +test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-counts + test_begin_subtest "Basic notmuch-search view in emacs" test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait) diff --git a/test/emacs.expected-output/notmuch-hello b/test/emacs.expected-output/notmuch-hello index 64b7e42..9666327 100644 --- a/test/emacs.expected-output/notmuch-hello +++ b/test/emacs.expected-output/notmuch-hello @@ -6,9 +6,10 @@ Saved searches: [edit] Search: -[Show all tags] +All tags: [show] Type a search query and hit RET to view matching threads. Edit saved searches with the `edit' button. Hit RET or click on a saved search or tag name to view matching threads. `=' refreshes this screen. `s' jumps to the search box. `q' to quit. + diff --git a/test/emacs.expected-output/notmuch-hello-new-section b/test/emacs.expected-output/notmuch-hello-new-section new file mode 100644 index 000..be7b26a --- /dev/null +++ b/test/emacs.expected-output/notmuch-hello-new-section @@ -0,0 +1,4 @@ +Test: [hide] + + 50 inbox + diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches b/test/emacs.expected-output/notmuch-hello-no-saved-searches index 7f8206a..744a8f1 100644 --- a/test/emacs.expected-output/notmuch-hello-no-saved-searches +++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches @@ -2,9 +2,10 @@ Search: -[Show all tags] +All tags: [show] Type a search query and hit RET to view matching threads. Edit saved searches with the `edit' button. Hit RET or click on a saved search or tag name to view matching threads. `=' refreshes this screen. `s' jumps to the search box. `q' to quit. + diff --git
[PATCH 1/2] emacs: User-defined sections in notmuch-hello
This patch makes the notmuch-hello screen fully customizable by allowing the user to add and remove arbitrary sections. It also provides some convenience functions for constructing sections, e.g. showing the unread message count for each tag. This is done by specifying a list of functions that will be run when notmuch-hello is invoked. --- emacs/notmuch-hello.el | 570 ++-- 1 files changed, 356 insertions(+), 214 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 65fde75..19756e9 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -55,26 +55,6 @@ :type 'boolean :group 'notmuch) -(defcustom notmuch-hello-tag-list-make-query nil - "Function or string to generate queries for the all tags list. - -This variable controls which query results are shown for each tag -in the \"all tags\" list. If nil, it will use all messages with -that tag. If this is set to a string, it is used as a filter for -messages having that tag (equivalent to \"tag:TAG and (THIS-VARIABLE)\"). -Finally this can be a function that will be called for each tag and -should return a filter for that tag, or nil to hide the tag." - :type '(choice (const :tag "All messages" nil) -(const :tag "Unread messages" "tag:unread") -(const :tag "Custom filter" string) -(const :tag "Custom filter function" function)) - :group 'notmuch) - -(defcustom notmuch-hello-hide-tags nil - "List of tags to be hidden in the \"all tags\"-section." - :type '(repeat string) - :group 'notmuch) - (defface notmuch-hello-logo-background 'class color) (background dark)) @@ -123,6 +103,73 @@ Typically \",\" in the US and UK and \".\" in Europe." (defvar notmuch-hello-recent-searches nil) +(define-widget 'notmuch-hello-tags-section 'lazy + "Customize-type for notmuch-hello tag-list sections." + :tag "Customized tag-list" + :type + (let ((opts +'((:title (string :tag "Title for this section")) + (:make-query (string :tag "Filter for each tag")) + (:make-count (string :tag "Different query to generate counts")) + (:hide-tags (repeat :tag "Tags that will be hidden" string)) + (:initially-hidden (boolean :tag "Hide this on startup?")) + (:hide-empty-tags (boolean :tag "Hide tags with no matching messages")) + (:hide-if-empty (boolean :tag "Hide if empty") +`(list (const :tag "" notmuch-hello-insert-tags-section) + (plist :inline t :options ,opts + +(define-widget 'notmuch-hello-query-section 'lazy + "Customize-type for custom saved-search-like sections" + :tag "Customized queries section" + :type + '(list (const :tag "" notmuch-hello-insert-query-list) +(string :tag "Title for this section") +(repeat :tag "Queries" +(cons (string :tag "Name") (string :tag "Query"))) +(plist :inline t + :options + ((:initially-hidden (boolean :tag "Hide this on startup?")) +(:hide-empty-tags + (boolean :tag "Hide tags with no matching messages")) +(:hide-if-empty (boolean :tag "Hide if empty")) + +(defcustom notmuch-hello-sections + (list #'notmuch-hello-insert-header + #'notmuch-hello-insert-saved-searches + #'notmuch-hello-insert-search + #'notmuch-hello-insert-recent-searches + #'notmuch-hello-insert-alltags + #'notmuch-hello-insert-footer) + "Sections for notmuch-hello. + +Each entry of this list should be a function of no arguments that +should return if notmuch-hello-target is produced as part of its +output and nil otherwise. For convenience an element can also be +a list of the form (FUNC ARG1 ARG2 .. ARGN) in which case FUNC +will be applied to the rest of the list. + +The functions will be run to construct the content of the +notmuch-hello buffer in the order they appear in this list." + :group 'notmuch + :type + '(repeat +(choice (function-item notmuch-hello-insert-header) + (function-item notmuch-hello-insert-saved-searches) + (function-item notmuch-hello-insert-search) + (function-item notmuch-hello-insert-recent-searches) + (function-item notmuch-hello-insert-alltags) + (function-item notmuch-hello-insert-footer) + notmuch-hello-tags-section + notmuch-hello-query-section))) + +;; only defined to avoid compilation warnings about free variables +(defvar notmuch-hello-target nil) + +(defvar notmuch-hello-hidden-sections nil + "List of query sections whose contents are hidden") + +(defvar notmuch-hello-first-run t) + (defun notmuch-hello-remember-search (search) (if (not (member search notmuch-hello-recent-searches)) (push search notmuch-hello-recent-searches)) @@ -238,12 +285,40 @@ should be. Returns a cons cell `(tags-per-line width)'." (* tags-per-line (+
[PATCH v2 0/2] emacs: User-defined sections in notmuch-hello
Rebased against current master and some improvements for using customize.
branchs and tags and merges oh my!
On Sat, Jul 2, 2011 at 07:44, David Bremner wrote: > > A third strategy is "git checkout master && git merge -s ours 0.6". > Then history will look like this: > > ?freeze > --.-.- master > ? \ ? ? ? ? ? / > ? ?--- > ? ? ? ? ? ? ? release > > As long as every patch on the release branch is already on master, -s > ours (which throws away all the changes from the side branch) is > reasonable. Remind me of why bugfix patches can't (usually) be applied to the release branch first, then merged into master? When the patch is (accidentally or otherwise) applied to master first, then I think you have no choice but to have it appear twice in the history, once in master and once in release, and using the model you describe above seems the most sensible way to do that.
branchs and tags and merges oh my!
On Sat, 2 Jul 2011 11:59:04 -0400, servilio wrote: > What about having Carl do the merging of features into a develop > branch[1], then the release manager prepares a release in a release > branch, merging back and tagging into master when release is ready? A > similar workflow could be followed for bugfix releases (branch to > bugfix/release branch, prepare, merge back to master, tag). We could also call the develop branch "master" and use something like "release" for the branch that contains the release history. This is is technically quite close to option #2, but perhaps conceptually clearer (and throwing in Tom's tagging idea). 0.7-pre 0.8-pre0.9-pre -.+--.+-.+- master \ / / .| / \ / 0.7 / +m--+-+m+ release 0.6 0.7.1 0.8 One difference in this version is that a merge from master onto release (and convenience tagging of master) occurs only when we are ready to release. If a bug fix release is desired, it can be done by committing/cherry-picking on release. d -- 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/20110702/b4deff86/attachment-0001.pgp>
branchs and tags and merges oh my!
On 1 July 2011 19:47, David Bremner wrote: > 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. What about having Carl do the merging of features into a develop branch[1], then the release manager prepares a release in a release branch, merging back and tagging into master when release is ready? A similar workflow could be followed for bugfix releases (branch to bugfix/release branch, prepare, merge back to master, tag). This workflow would keep a nice useful history while allowing even more independence between the feature merging and release process, what do you think? Servilio [1] Or next, or whatever other name is better understood by the community.
branchs and tags and merges oh my!
On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner wrote: > > 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. > A third strategy is "git checkout master && git merge -s ours 0.6". Then history will look like this: freeze --.-.- master \ / --- release As long as every patch on the release branch is already on master, -s ours (which throws away all the changes from the side branch) is reasonable. This has the advantage that "git describe master" starts to count from 0.6 instead of 0.5. Currently e.g. "make dist" on master is making notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the "increasingly innacurately named" effect, that is probably not what we want. d -- 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/20110702/32aa0752/attachment.pgp>
branchs and tags and merges oh my!
On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner wrote: > This has the advantage that "git describe master" starts to count from > 0.6 instead of 0.5. Currently e.g. "make dist" on master is making > notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the > "increasingly innacurately named" effect, that is probably not what we > want. Another solution to this is to tag master just after branching with something like 0.7-pre. Tom
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-jrollins at finestructure.net" > thanks a lot David. I can confirm that it works for me. Andreas
Preventing the user shooting themself in the foot
On Fri, 1 Jul 2011 11:28:10 +1000, Brian May wrote: > 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. 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 > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter
Re: branchs and tags and merges oh my!
On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner da...@tethera.net wrote: 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. A third strategy is git checkout master git merge -s ours 0.6. Then history will look like this: freeze --.-.- master \ / --- release As long as every patch on the release branch is already on master, -s ours (which throws away all the changes from the side branch) is reasonable. This has the advantage that git describe master starts to count from 0.6 instead of 0.5. Currently e.g. make dist on master is making notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the increasingly innacurately named effect, that is probably not what we want. d pgpGQ4jg6rpr9.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 0/2] emacs: User-defined sections in notmuch-hello
Rebased against current master and some improvements for using customize. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] emacs: User-defined sections in notmuch-hello
This patch makes the notmuch-hello screen fully customizable by allowing the user to add and remove arbitrary sections. It also provides some convenience functions for constructing sections, e.g. showing the unread message count for each tag. This is done by specifying a list of functions that will be run when notmuch-hello is invoked. --- emacs/notmuch-hello.el | 570 ++-- 1 files changed, 356 insertions(+), 214 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 65fde75..19756e9 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -55,26 +55,6 @@ :type 'boolean :group 'notmuch) -(defcustom notmuch-hello-tag-list-make-query nil - Function or string to generate queries for the all tags list. - -This variable controls which query results are shown for each tag -in the \all tags\ list. If nil, it will use all messages with -that tag. If this is set to a string, it is used as a filter for -messages having that tag (equivalent to \tag:TAG and (THIS-VARIABLE)\). -Finally this can be a function that will be called for each tag and -should return a filter for that tag, or nil to hide the tag. - :type '(choice (const :tag All messages nil) -(const :tag Unread messages tag:unread) -(const :tag Custom filter string) -(const :tag Custom filter function function)) - :group 'notmuch) - -(defcustom notmuch-hello-hide-tags nil - List of tags to be hidden in the \all tags\-section. - :type '(repeat string) - :group 'notmuch) - (defface notmuch-hello-logo-background 'class color) (background dark)) @@ -123,6 +103,73 @@ Typically \,\ in the US and UK and \.\ in Europe. (defvar notmuch-hello-recent-searches nil) +(define-widget 'notmuch-hello-tags-section 'lazy + Customize-type for notmuch-hello tag-list sections. + :tag Customized tag-list + :type + (let ((opts +'((:title (string :tag Title for this section)) + (:make-query (string :tag Filter for each tag)) + (:make-count (string :tag Different query to generate counts)) + (:hide-tags (repeat :tag Tags that will be hidden string)) + (:initially-hidden (boolean :tag Hide this on startup?)) + (:hide-empty-tags (boolean :tag Hide tags with no matching messages)) + (:hide-if-empty (boolean :tag Hide if empty) +`(list (const :tag notmuch-hello-insert-tags-section) + (plist :inline t :options ,opts + +(define-widget 'notmuch-hello-query-section 'lazy + Customize-type for custom saved-search-like sections + :tag Customized queries section + :type + '(list (const :tag notmuch-hello-insert-query-list) +(string :tag Title for this section) +(repeat :tag Queries +(cons (string :tag Name) (string :tag Query))) +(plist :inline t + :options + ((:initially-hidden (boolean :tag Hide this on startup?)) +(:hide-empty-tags + (boolean :tag Hide tags with no matching messages)) +(:hide-if-empty (boolean :tag Hide if empty)) + +(defcustom notmuch-hello-sections + (list #'notmuch-hello-insert-header + #'notmuch-hello-insert-saved-searches + #'notmuch-hello-insert-search + #'notmuch-hello-insert-recent-searches + #'notmuch-hello-insert-alltags + #'notmuch-hello-insert-footer) + Sections for notmuch-hello. + +Each entry of this list should be a function of no arguments that +should return if notmuch-hello-target is produced as part of its +output and nil otherwise. For convenience an element can also be +a list of the form (FUNC ARG1 ARG2 .. ARGN) in which case FUNC +will be applied to the rest of the list. + +The functions will be run to construct the content of the +notmuch-hello buffer in the order they appear in this list. + :group 'notmuch + :type + '(repeat +(choice (function-item notmuch-hello-insert-header) + (function-item notmuch-hello-insert-saved-searches) + (function-item notmuch-hello-insert-search) + (function-item notmuch-hello-insert-recent-searches) + (function-item notmuch-hello-insert-alltags) + (function-item notmuch-hello-insert-footer) + notmuch-hello-tags-section + notmuch-hello-query-section))) + +;; only defined to avoid compilation warnings about free variables +(defvar notmuch-hello-target nil) + +(defvar notmuch-hello-hidden-sections nil + List of query sections whose contents are hidden) + +(defvar notmuch-hello-first-run t) + (defun notmuch-hello-remember-search (search) (if (not (member search notmuch-hello-recent-searches)) (push search notmuch-hello-recent-searches)) @@ -238,12 +285,40 @@ should be. Returns a cons cell `(tags-per-line width)'. (* tags-per-line (+ 9 1 tags-per-line -(defun
[PATCH 2/2] emacs: Tests for user-defined sections
--- test/emacs | 37 test/emacs.expected-output/notmuch-hello |3 +- .../notmuch-hello-new-section |4 ++ .../notmuch-hello-no-saved-searches|3 +- .../notmuch-hello-section-before | 18 + .../notmuch-hello-section-counts |5 +++ .../notmuch-hello-section-hidden-tag |4 ++ .../notmuch-hello-section-with-empty |4 ++ .../emacs.expected-output/notmuch-hello-with-empty |3 +- 9 files changed, 78 insertions(+), 3 deletions(-) create mode 100644 test/emacs.expected-output/notmuch-hello-new-section create mode 100644 test/emacs.expected-output/notmuch-hello-section-before create mode 100644 test/emacs.expected-output/notmuch-hello-section-counts create mode 100644 test/emacs.expected-output/notmuch-hello-section-hidden-tag create mode 100644 test/emacs.expected-output/notmuch-hello-section-with-empty diff --git a/test/emacs b/test/emacs index 53f455a..e5ae509 100755 --- a/test/emacs +++ b/test/emacs @@ -34,6 +34,43 @@ test_emacs '(let ((notmuch-saved-searches (test-output))' test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-no-saved-searches +test_begin_subtest User defined section with inbox tag +test_emacs (let ((notmuch-hello-sections + (list (lambda () (notmuch-hello-insert-query-list + \Test: \ '((\inbox\ . \tag:inbox\))) + (notmuch-hello) + (test-output)) +test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-new-section + +test_begin_subtest User defined section with empty, hidden entry +test_emacs (let ((notmuch-hello-sections + (list (lambda () (notmuch-hello-insert-query-list + \Test-with-empty:\ + '((\inbox\ . \tag:inbox\) + (\doesnotexist\ . \tag:doesnotexist\)) + :hide-empty-tags t) + (notmuch-hello) + (test-output)) +test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-with-empty + +test_begin_subtest User defined section, unread tag filtered out +test_emacs (let ((notmuch-hello-sections + (list (lambda () (notmuch-hello-insert-tags-section + :title \Test-with-filtered: \ + :hide-tags '(\unread\)) + (notmuch-hello) + (test-output)) +test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-hidden-tag + +test_begin_subtest User defined section, different query for counts +test_emacs (let ((notmuch-hello-sections + (list (lambda () (notmuch-hello-insert-tags-section + :title \Test-with-counts: \ + :make-count \tag:signed\) + (notmuch-hello) + (test-output)) +test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-counts + test_begin_subtest Basic notmuch-search view in emacs test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) diff --git a/test/emacs.expected-output/notmuch-hello b/test/emacs.expected-output/notmuch-hello index 64b7e42..9666327 100644 --- a/test/emacs.expected-output/notmuch-hello +++ b/test/emacs.expected-output/notmuch-hello @@ -6,9 +6,10 @@ Saved searches: [edit] Search: -[Show all tags] +All tags: [show] Type a search query and hit RET to view matching threads. Edit saved searches with the `edit' button. Hit RET or click on a saved search or tag name to view matching threads. `=' refreshes this screen. `s' jumps to the search box. `q' to quit. + diff --git a/test/emacs.expected-output/notmuch-hello-new-section b/test/emacs.expected-output/notmuch-hello-new-section new file mode 100644 index 000..be7b26a --- /dev/null +++ b/test/emacs.expected-output/notmuch-hello-new-section @@ -0,0 +1,4 @@ +Test: [hide] + + 50 inbox + diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches b/test/emacs.expected-output/notmuch-hello-no-saved-searches index 7f8206a..744a8f1 100644 --- a/test/emacs.expected-output/notmuch-hello-no-saved-searches +++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches @@ -2,9 +2,10 @@ Search: -[Show all tags] +All tags: [show] Type a search query and hit RET to view matching threads. Edit saved searches with the `edit' button. Hit RET or click on a saved search or tag name to view matching threads. `=' refreshes this screen. `s' jumps to the search box. `q' to quit. + diff --git
Re: problem with message/rfc822 parts
On Sat, 02 Jul 2011 02:23:34 +0100, Andreas Amann a.am...@ucc.ie wrote: It's a known problem. As a short term fix, try the patches of id:1307320169-29905-1-git-send-email-jroll...@finestructure.net Or use `notmuch-show-view-raw-message' (bound to 'V'). 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 Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: branchs and tags and merges oh my!
On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner da...@tethera.net wrote: This has the advantage that git describe master starts to count from 0.6 instead of 0.5. Currently e.g. make dist on master is making notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the increasingly innacurately named effect, that is probably not what we want. Another solution to this is to tag master just after branching with something like 0.7-pre. Tom ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Possible bug: wrong from address when forwarding
--- Either enable `notmuch-always-prompt-for-sender', or apply this quick-fix patch, which uses `name' and `primary_email' as configured in your .notmuch-config if aforementioned isn't enabled. emacs/notmuch-mua.el |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 274c5da..27c6884 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -213,7 +213,9 @@ the From: address first. (user-full-name (car address-components)) (user-mail-address (cadr address-components))) (notmuch-mua-forward-message)) -(notmuch-mua-forward-message))) +(let* ((user-full-name (notmuch-user-name)) + (user-mail-address (notmuch-user-primary-email))) +(notmuch-mua-forward-message (defun notmuch-mua-new-reply (query-string optional prompt-for-sender) Invoke the notmuch reply window. -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: branchs and tags and merges oh my!
On 1 July 2011 19:47, David Bremner da...@tethera.net wrote: On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard kei...@keithp.com 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. What about having Carl do the merging of features into a develop branch[1], then the release manager prepares a release in a release branch, merging back and tagging into master when release is ready? A similar workflow could be followed for bugfix releases (branch to bugfix/release branch, prepare, merge back to master, tag). This workflow would keep a nice useful history while allowing even more independence between the feature merging and release process, what do you think? Servilio [1] Or next, or whatever other name is better understood by the community. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: branchs and tags and merges oh my!
On Sat, 2 Jul 2011 11:59:04 -0400, servilio servi...@gmail.com wrote: What about having Carl do the merging of features into a develop branch[1], then the release manager prepares a release in a release branch, merging back and tagging into master when release is ready? A similar workflow could be followed for bugfix releases (branch to bugfix/release branch, prepare, merge back to master, tag). We could also call the develop branch master and use something like release for the branch that contains the release history. This is is technically quite close to option #2, but perhaps conceptually clearer (and throwing in Tom's tagging idea). 0.7-pre 0.8-pre0.9-pre -.+--.+-.+- master \ / / .| / \ / 0.7 / +m--+-+m+ release 0.6 0.7.1 0.8 One difference in this version is that a merge from master onto release (and convenience tagging of master) occurs only when we are ready to release. If a bug fix release is desired, it can be done by committing/cherry-picking on release. d pgpsFdga7Sh7r.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: branchs and tags and merges oh my!
On Sat, Jul 2, 2011 at 07:44, David Bremner da...@tethera.net wrote: A third strategy is git checkout master git merge -s ours 0.6. Then history will look like this: freeze --.-.- master \ / --- release As long as every patch on the release branch is already on master, -s ours (which throws away all the changes from the side branch) is reasonable. Remind me of why bugfix patches can't (usually) be applied to the release branch first, then merged into master? When the patch is (accidentally or otherwise) applied to master first, then I think you have no choice but to have it appear twice in the history, once in master and once in release, and using the model you describe above seems the most sensible way to do that. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] test: add emacs test for hiding message when point is at invisible text
Human-friendly scenario: * open a thread which has at least 2 messages in notmuch-show view * hide the first message * move to the first line of the second message * press C-a (bound to `beginning-of-visual-line') * press RET (bound to `notmuch-show-toggle-message') Result: the first message is shown Expected result: the second message is hidden or shown Currently the test is failing. The bug will be fixed by a subsequent patch. --- test/emacs | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/test/emacs b/test/emacs index 53f455a..173d371 100755 --- a/test/emacs +++ b/test/emacs @@ -347,4 +347,15 @@ 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 'Hiding message when point is at invisible text' +test_emacs '(notmuch-show id:1258471718-6781-2-git-send-email-dotted...@dottedmag.net) + (notmuch-show-toggle-message) + (test-visible-output EXPECTED) + (notmuch-show-toggle-message) + (goto-char (previous-single-char-property-change + (point) '\''invisible)) + (notmuch-show-toggle-message) + (test-visible-output)' +test_expect_equal_file OUTPUT EXPECTED + test_done -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
