Re: [RFC PATCH v2 0/3] lib/cli/emacs: limit number of messages in search results
On Mon, 31 Oct 2011 23:18:07 +0200, Jani Nikula wrote: > > I'm still marking it as RFC. It works for me, but patch 1 might be deemed > unacceptable. > Hi Jani; Is just because it add a function to the library that you think this might be problematic? I don't think we are super-dogmatic about the library never growing. When notmuch started, there were no bindings, so in retrospect maybe more functionality went into the CLI than might happen if we started from scratch. If I remember Carl's statement correctly, one rule is that stuff in the library should not require configuration. Just my personal view, David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Displaying tags with many messages very slow in Emacs
On 2011, Oct 31, at 19:25 , Daniel Schoepe wrote: > On Mon, 31 Oct 2011 16:43:22 +0100, bnt wrote: >> I am not too proficient with the patch utility. Is there some kind of >> scheduled git commits timeline? > > Unfortunately, there's a huge number of outstanding patches at the > moment, so it's impossible to say when/if it will be applied. > >> If not, I guess it will be a good time to learn patching. > > There's no need to use the patch binary directly when the patches are > sent in a format git understands, which is generally the case here. To > apply patches from a thread, you can use `git am patches.mbox' where > patches.mbox contains the mails with the patches. > > If you're using the emacs UI for notmuch, you can open only those > messages with the patches you want in a thread and pipe them to an mbox > file like this: > > C-u | cat > ~/patches.mbox > > If there are no conflicts due to more recent changes to the repository, > git am patches.mbox will apply them using the commit messages from the > mails. > > FWIW: There's another more recent series of patches that accomplishes a > similar goal: id:"cover.1319833617.git.j...@nikula.org" > > Cheers, > Daniel Thank you so much for the explanation, and thanks to Jani for those patches. I will work my way into applying them. As just a plain user, I was wondering if it would be possible to have a "dev" or "untested" branch in the git repo, where one could just get all the latest patches? Of course it would not be desirable if it would just complicate the developers life. Thank you so much once again, Sam ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Patch review/application process
On Tue, 25 Oct 2011 22:42:33 +0200, Daniel Schoepe wrote: >. There is also a number of patches that have been reviewed by > long-term contributors, but are then seemingly forgotten (I can find > some concrete examples of this, if this claim is in doubt). Maybe you can tag those patches as "notmuch::reviewed" using nmbug? [1] My idea is that notmuch search tag:notmuch::patch and tag:notmuch::reviewed should give a kind of consensus set of "ready to go" patch sets. Don't worry about if I or someone else disagrees with your assessment, we can always untag it, and leave a comment in the commit log. [2] There are also plenty of patches that are not reviewed at all. I'm not defending the state of patch integration, but I think we could use some more reviews as well. d [1]: http://notmuchmail.org/nmbug/ [2]: nmbug log $id could be defined as something like "cd $HOME/.nmbug && git log -- tags/$(echo $id | sha1sum -)" pgp3clgVyGTiC.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Patch review/application process
On Tue, 01 Nov 2011 11:28:45 -0300, David Bremner wrote: > Maybe you can tag those patches as "notmuch::reviewed" using nmbug? [1] > My idea is that > >notmuch search tag:notmuch::patch and tag:notmuch::reviewed > > should give a kind of consensus set of "ready to go" patch sets. Don't forget notmuch::applied, which I think is actually one of the most important. Review is easy to see by looking at the patch thread. Being able to easily find which patches have not yet been applied to master is what I'm most looking forward to. jamie. pgph9ZBUnIFDJ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
set test prereqs (Emacs, GDB, GPG) v4
Rebased to current master. Previous version: id:"1307016220-17509-1-git-send-email-pie...@praet.org" Discussion: id:"1317660447-27520-1-git-send-email-schno...@schnouki.net" ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] test: add 'GnuPG' prereq to dependent 'crypto' tests
Adds a new test that checks for the presence of 'gpg',
and adds that test as a prereq to all subsequent tests
that rely on GnuPG.
This causes tests with unmet dependencies to be skipped.
---
test/crypto | 33 +++--
1 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/test/crypto b/test/crypto
index 0af4aa8..3795926 100755
--- a/test/crypto
+++ b/test/crypto
@@ -7,6 +7,11 @@
test_description='PGP/MIME signature verification and decryption'
. ./test-lib.sh
+# GnuPG is a prereq.
+test_expect_success "prereq: GnuPG is present" "which gpg" \
+&& test_set_prereq GPG
+
+
add_gnupg_home ()
{
local output
@@ -31,7 +36,7 @@ FINGERPRINT=$(gpg --no-tty --list-secret-keys --with-colons
--fingerprint | grep
# although I can't figure out why
add_email_corpus
-test_expect_success 'emacs delivery of signed message' \
+test_expect_success GPG 'emacs delivery of signed message' \
'emacs_deliver_message \
"test signed message 001" \
"This is a test signed message." \
@@ -64,7 +69,7 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/pgp-signature"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
@@ -99,7 +104,7 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/pgp-signature"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
@@ -132,7 +137,7 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/pgp-signature"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
mv "${GNUPGHOME}"{.bak,}
@@ -141,7 +146,7 @@ mv "${GNUPGHOME}"{.bak,}
cat OUTPUT
-test_expect_equal_file OUTPUT TESTATTACHMENT
+test_expect_equal_file GPG OUTPUT TESTATTACHMENT
test_begin_subtest "decryption failure with missing key"
mv "${GNUPGHOME}"{,.bak}
@@ -258,12 +263,12 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/octet-stream"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
mv "${GNUPGHOME}"{.bak,}
-test_expect_success 'emacs delivery of encrypted + signed message' \
+test_expect_success GPG 'emacs delivery of encrypted + signed message' \
'emacs_deliver_message \
"test encrypted message 002" \
"This is another test encrypted message.\n" \
@@ -298,7 +303,7 @@ expected='[[[{"id": "X",
"content-type": "text/plain",
"content": "This is another test encrypted message.\n"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
@@ -310,7 +315,7 @@ Subject: Re: test encrypted message 002
On 01 Jan 2000 12:00:00 -, Notmuch Test Suite
wrote:
> This is another test encrypted message.'
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
@@ -351,7 +356,7 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/pgp-signature"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
--
1.7.7.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/4] test: add 'Emacs' prereq to dependent 'crypto' tests
Adds a new test that checks for the presence of 'emacs',
and adds that test as a prereq to all subsequent tests
that rely on Emacs.
This causes tests with unmet dependencies to be skipped.
---
test/crypto | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/test/crypto b/test/crypto
index 3795926..4a00c00 100755
--- a/test/crypto
+++ b/test/crypto
@@ -7,10 +7,21 @@
test_description='PGP/MIME signature verification and decryption'
. ./test-lib.sh
+# Emacs is a prereq.
+test_expect_success "prereq: Emacs is present" "which emacs" \
+&& test_set_prereq EMACS
+
# GnuPG is a prereq.
test_expect_success "prereq: GnuPG is present" "which gpg" \
&& test_set_prereq GPG
+# Some tests have multiple prereqs, but the test_expect_* functions
+# accept only a single argument as prereq tag, and using test_have_prereq
+# in and around tests causes various errors for me, so a dirty workaround
+# will have to do for the time being.
+test_have_prereq EMACS && test_have_prereq GPG \
+&& test_set_prereq EMACS+GPG
+
add_gnupg_home ()
{
@@ -36,7 +47,7 @@ FINGERPRINT=$(gpg --no-tty --list-secret-keys --with-colons
--fingerprint | grep
# although I can't figure out why
add_email_corpus
-test_expect_success GPG 'emacs delivery of signed message' \
+test_expect_success EMACS+GPG 'emacs delivery of signed message' \
'emacs_deliver_message \
"test signed message 001" \
"This is a test signed message." \
@@ -146,7 +157,7 @@ mv "${GNUPGHOME}"{.bak,}
cat
[PATCH 3/4] test: add 'Emacs' prereq to dependent 'emacs' tests
Adds a new test that checks for the presence of 'emacs',
and adds that test as a prereq to all subsequent tests
that rely on Emacs.
This causes tests with unmet dependencies to be skipped.
---
test/emacs | 65 ---
1 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/test/emacs b/test/emacs
index 0303d7d..8b1e5e4 100755
--- a/test/emacs
+++ b/test/emacs
@@ -3,6 +3,11 @@
test_description="emacs interface"
. test-lib.sh
+# Emacs is a prereq.
+test_expect_success "prereq: Emacs is present" "which emacs" \
+&& test_set_prereq EMACS
+
+
EXPECTED=$TEST_DIRECTORY/emacs.expected-output
add_email_corpus
@@ -10,7 +15,7 @@ add_email_corpus
test_begin_subtest "Basic notmuch-hello view in emacs"
test_emacs '(notmuch-hello)
(test-output)'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-hello
test_begin_subtest "Saved search with 0 results"
test_emacs '(let ((notmuch-show-empty-saved-searches t)
@@ -20,20 +25,20 @@ test_emacs '(let ((notmuch-show-empty-saved-searches t)
("empty" . "tag:doesnotexist"
(notmuch-hello)
(test-output))'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-hello-with-empty
test_begin_subtest "No saved searches displayed (all with 0 results)"
test_emacs '(let ((notmuch-saved-searches
'\''(("empty" . "tag:doesnotexist"
(notmuch-hello)
(test-output))'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-no-saved-searches
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-hello-no-saved-searches
test_begin_subtest "Basic notmuch-search view in emacs"
test_emacs '(notmuch-search "tag:inbox")
(notmuch-test-wait)
(test-output)'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-search-tag-inbox
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-search-tag-inbox
test_begin_subtest "Navigation of notmuch-hello to search results"
test_emacs '(notmuch-hello)
@@ -42,13 +47,13 @@ test_emacs '(notmuch-hello)
(widget-button-press (point))
(notmuch-test-wait)
(test-output)'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-view-inbox
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-hello-view-inbox
test_begin_subtest "Basic notmuch-show view in emacs"
maildir_storage_thread=$(notmuch search --output=threads
id:20091117190054.gu3...@dottiness.seas.harvard.edu)
test_emacs "(notmuch-show \"$maildir_storage_thread\")
(test-output)"
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
+test_expect_equal_file EMACS OUTPUT
$EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "notmuch-show for message with invalid From"
add_message "[subject]=\"message-with-invalid-from\"" \
@@ -64,7 +69,7 @@ Date: Tue, 05 Jan 2001 15:43:57 -
This is just a test message (#1)
EOF
-test_expect_equal_file OUTPUT EXPECTED
+test_expect_equal_file EMACS OUTPUT EXPECTED
test_begin_subtest "Navigation of notmuch-search to thread view"
test_emacs '(notmuch-search "tag:inbox")
@@ -74,7 +79,7 @@ test_emacs '(notmuch-search "tag:inbox")
(notmuch-search-show-thread)
(notmuch-test-wait)
(test-output)'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
+test_expect_equal_file EMACS OUTPUT
$EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "Add tag from search view"
os_x_darwin_thread=$(notmuch search --output=threads
id:ddd65cda0911171950o4eea4389v86de9525e4605...@mail.gmail.com)
@@ -82,26 +87,26 @@ test_emacs "(notmuch-search \"$os_x_darwin_thread\")
(notmuch-test-wait)
(notmuch-search-add-tag \"tag-from-search-view\")"
output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
-test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
tag-from-search-view unread)"
+test_expect_equal EMACS "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
tag-from-search-view unread)"
test_begin_subtest "Remove tag from search view"
test_emacs "(notmuch-search \"$os_x_darwin_thread\")
(notmuch-test-wait)
(notmuch-search-remove-tag \"tag-from-search-view\")"
output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
-test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
unread)"
+test_expect_equal EMACS "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
unread)"
[PATCH 4/4] test: add 'Emacs' prereq to dependent 'emacs-large-search-buffer' tests
Adds a new test that checks for the presence of 'emacs', and adds that test as a prereq to all subsequent tests that rely on Emacs. This causes tests with unmet dependencies to be skipped. --- test/emacs-large-search-buffer |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/test/emacs-large-search-buffer b/test/emacs-large-search-buffer index 6095e9d..5757380 100755 --- a/test/emacs-large-search-buffer +++ b/test/emacs-large-search-buffer @@ -2,6 +2,11 @@ test_description="Emacs with large search results buffer" . test-lib.sh +# Emacs is a prereq. +test_expect_success "prereq: Emacs is present" "which emacs" \ +&& test_set_prereq EMACS + + x=xx # 10 x=$x$x$x$x$x$x$x$x$x$x # 100 x=$x$x$x$x$x$x$x$x$x # 900 @@ -27,7 +32,7 @@ test_emacs '(notmuch-search "*") (notmuch-test-wait) (test-output)' sed -i -e s', *, ,g' -e 's/xxx*/[BLOB]/g' OUTPUT -test_expect_equal_file OUTPUT EXPEXTED +test_expect_equal_file EMACS OUTPUT EXPEXTED test_begin_subtest "Ensure that emacs doesn't drop error messages" test_emacs '(notmuch-search "--this-option-does-not-exist") @@ -38,6 +43,6 @@ Error: Unexpected output from notmuch search: Unrecognized option: --this-option-does-not-exist End of search results. (process returned 1) EOF -test_expect_equal_file OUTPUT EXPEXTED +test_expect_equal_file EMACS OUTPUT EXPEXTED test_done -- 1.7.7.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 00/13] Test prereqs and screen-based Emacs tests
On Mon, 3 Oct 2011 18:47:14 +0200, Thomas Jost wrote:
> Here it is: a rebased version of Pieter's patch series adding prereqs for the
> emacs and crypto tests [1], and Dmitry's patches for running emacs inside
> screen
> in the test suite [2]. (Please note that this one also includes fixes to
> improve
> hidden signatures handling in notmuch-show-advance-and-archive.)
>
I'm pleased to see these patches haven't moved to binary oblivion yet!
> I had to do several changes to the original patches:
> - prereqs are not tested using test_expect_success as they were in Pieter's
> original patches, but using a new function called test_set_bin_prereq. I
> wrote
> this before the gdb prereq was added, hence the different way to set it.
>
Indeed preferrable to using `test_expect_success' due to no longer
overzealously reporting missing prereqs as failures, as well as getting
rid of some duplication; This should also be used in the atomicity tests.
> - some fixes in Pieter's patches so that it actually works when gpg is not
> installed. Can't exactly remember what (...but you can just check his
> original
> patches), but in the end it was working fine in a chroot without gpg.
>
Correct. I only added prereqs to actual tests (i.e. calls to
`test_expect_success', `test_expect_equal', and
`test_expect_equal_file'), while they should also have been added to
both the `add_gnupg_home' function and the initialization of
${FINGERPRINT}.
> - I added a little patch to smtp-dummy that makes the test suite work again in
> Emacs 24 (tested with emacs-pretest 24.0.90).
>
> Here are the results when running the test suite on my computer:
> - without GNU Screen:
> All 247 tests behaved as expected (1 expected failure).
> 46 tests skipped.
> - with GNU Screen:
> 242/247 tests passed.
> 2 broken tests failed as expected.
> 3 tests failed.
>
> (The 3 failed tests come from some trouble with Emacs 24, I'll try to fix this
> later.)
>
> *Many* thanks to Dmitry Kurochkin and Pieter Praet for their work!
>
Thanks to you as well! All this duplication of effort is a real shame
though. I'd also have preferred your fixes being in separate commits.
I'll be commenting on these modified commits where needed, and have
re-submitted my original series (rebased to current master) in a new
thread [1].
> Regards,
> Thomas
>
> [1] id:"1307016220-17509-1-git-send-email-pie...@praet.org"
> [2] id:"1309496122-4965-1-git-send-email-dmitry.kuroch...@gmail.com"
>
> Dmitry Kurochkin (7):
> test: run emacs inside screen
> test: avoid using screen(1) configuration files
> test: do not set frame width in emacs
> test: `notmuch-show-advance-and-archive' with invisible signature
> emacs: improve hidden signatures handling in
> notmuch-show-advance-and-archive
> emacs: remove no longer used functions from notmuch-show.el
> emacs: remove unused `point-invisible-p' function
>
> Pieter Praet (4):
> test: add 'GnuPG' prereq to dependent 'crypto' tests
> test: add 'Emacs' prereq to dependent 'crypto' tests
> test: add 'Emacs' prereq to dependent 'emacs' tests
> test: add 'Emacs' prereq to dependent 'emacs-large-search-buffer'
> tests
>
> Thomas Jost (2):
> test: define a helper function for defining prereqs on executables
> test: make smtp-dummy work with Emacs 24
>
> emacs/notmuch-lib.el | 15 ---
> emacs/notmuch-show.el | 25 ---
> test/crypto| 46 ++---
> test/emacs | 85 ---
> test/emacs-large-search-buffer |9 +++-
> test/smtp-dummy.c |2 +-
> test/test-lib.el |3 -
> test/test-lib.sh | 31 +--
> 8 files changed, 127 insertions(+), 89 deletions(-)
>
> --
> 1.7.6.4
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Peace
--
Pieter
[1] id:"1320176954-4897-1-git-send-email-pie...@praet.org"
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Patch review/application process
On Tue, 01 Nov 2011 08:55:09 -0700, Jameson Graef Rollins wrote: > On Tue, 01 Nov 2011 11:28:45 -0300, David Bremner wrote: > > Maybe you can tag those patches as "notmuch::reviewed" using nmbug? [1] > > My idea is that > > > >notmuch search tag:notmuch::patch and tag:notmuch::reviewed > > > > should give a kind of consensus set of "ready to go" patch sets. > > Don't forget notmuch::applied, which I think is actually one of the most > important. Review is easy to see by looking at the patch thread. Being > able to easily find which patches have not yet been applied to master is > what I'm most looking forward to. Jamie knows this from IRC, but I have been using "notmuch::pushed" for this. One thing I think we need to clarify a bit is are we tagging whole threads or individual messages in the database. Because of the way notmuch search works, I had been tagging whole threads with notmuch::pushed (effectively to "mute" them) in the search notmuch search tag:notmuch::patch and \ not tag:notmuch::pushed This is a bit aesthetically unappealing, anad every time someone replies to a thread it is effectively unmuted. Since we don't have thread tagging yet (where e.g. tags are automagically applied to new messages I was thinking it might work have a tag like "notmuch::todo" and something like the following workflow (for patches) initially tag +notmuch::patch +notmuch::todo then when we "dispose" of the patch somehow, remove the notmuch::todo tag and replace with notmuch::pushed notmuch::obsolete or... Then we could do e.g. notmuch search tag:notmuch::patch and tag:notmuch::todo and tag:notmuch::reviewed to get an "integrators queue" (Well, the more like an unordered pile than a queue. One problem at a time). David pgpmWzflpbzIu.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 03/13] test: add 'Emacs' prereq to dependent 'crypto' tests
On Mon, 3 Oct 2011 18:47:17 +0200, Thomas Jost wrote: > [...] The SCREEN prereq would preferrably be added in a separate commit. Also, you appear to have given *every* test the EMACS+GPG prereq, while only the ones using `emacs_deliver_message' require EMACS. Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 04/13] test: add 'Emacs' prereq to dependent 'emacs' tests
On Mon, 3 Oct 2011 18:47:18 +0200, Thomas Jost wrote: > [...] Nice catches @ - "Sending a message via (fake) SMTP" - "Hiding message following HTML part" (though I think the latter test wasn't there yet when I submitted my patch series) New "issues": - The SCREEN prereq would preferrably be added in a separate commit. - @ "Verify that sent messages are saved/searchable (via FCC)": This doesn't need an EMACS prereq. - @ "Reply within emacs": `sed' will want to treat "EMACS" as an input file, so I think you meant to do this: test_have_prereq EMACS \ && sed -i -e 's/^In-Reply-To: <.*>$/In-Reply-To: /' OUTPUT Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: logically group def{custom,face}s
On Tue, 18 Oct 2011 08:18:18 -0700, Jameson Graef Rollins wrote: > On Mon, 10 Oct 2011 15:49:03 +0200, Daniel Schoepe wrote: > > On Tue, 5 Jul 2011 20:33:00 +0200, Pieter Praet wrote: > > > To allow for expansion whilst keeping everything tidy and organized, > > > move all defcustom/defface variables to the following subgroups, > > > defined in notmuch-lib.el: > > > > Since the customize page for notmuch is getting pretty crowded, I think > > this patch is a good idea and should be applied. > > Agreed. > > jamie. Thanks for testing, Daniel and Jameson! It still applies cleanly, so if there's anything preventing it from being merged in, I'd like to hear about it. Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 04/13] test: add 'Emacs' prereq to dependent 'emacs' tests
On Tue, 01 Nov 2011 20:57:59 +0100, Pieter Praet wrote: > On Mon, 3 Oct 2011 18:47:18 +0200, Thomas Jost wrote: > [...] > - @ "Verify that sent messages are saved/searchable (via FCC)": > > This doesn't need an EMACS prereq. > [...] My mistake, scrap this one. Without Emacs, there wouldn't be a sent message to begin with, so the prereq is valid. Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 03/13] test: add 'Emacs' prereq to dependent 'crypto' tests
On Tue, 01 Nov 2011 20:56:17 +0100, Pieter Praet wrote: > On Mon, 3 Oct 2011 18:47:17 +0200, Thomas Jost wrote: > [...] > > Also, you appear to have given *every* test the EMACS+GPG prereq, > while only the ones using `emacs_deliver_message' require EMACS. > > [...] Again, my mistake. All subsequent tests appear to be using the message sent using Emacs (is this a good idea?), so the new prereqs are valid. Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: set test prereqs (Emacs, GDB, GPG) v4
On Tue, Nov 01, 2011 at 08:49:10PM +0100, Pieter Praet wrote: Rebased to current master. Previous version: id:"1307016220-17509-1-git-send-email-pie...@praet.org" Discussion: id:"1317660447-27520-1-git-send-email-schno...@schnouki.net" Thanks for the nice work! I want to share one thing which came up to my mind during reading through them. Since we require bash for tests, we might go for using bash's builtin 'type -P foo' instead of 'which foo'. Not that it's important, just wondered "why not?" -alip pgpi6XDhoIY2r.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] test: add 'GnuPG' prereq to dependent 'crypto' tests
On Tue, 1 Nov 2011 20:49:11 +0100, Pieter Praet wrote: > -test_expect_success 'emacs delivery of signed message' \ > +test_expect_success GPG 'emacs delivery of signed message' \ Hi, Pieter and Thomas. Thanks for all the work on this, but I have one issue. Is there a way we can do this without adding a new argument to every test function? For some reason I really don't like that solution. It seems too invasive. Can't we have something that works more like test_subtest_known_broken, that modifies the test environment, rather than add an argument to every call of every testing function? jamie. pgpOf5wbifOZ0.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Patch review/application process
On Tue, 01 Nov 2011 16:55:03 -0300, David Bremner wrote: > One thing I think we need to clarify a bit is are we tagging whole > threads or individual messages in the database. Because of the way > notmuch search works, I had been tagging whole threads with > notmuch::pushed (effectively to "mute" them) in the search > > notmuch search tag:notmuch::patch and \ > not tag:notmuch::pushed > > This is a bit aesthetically unappealing, anad every time someone replies > to a thread it is effectively unmuted. I have to say that I am very much against tagging threads with tags that are really only applicable to specific messages, ie. ::patch, ::pushed (I prefer ::applied, but whatever), etc. For instance, a thread maybe contain multiple patches, but it is not itself a patch. Tagging entire threads as ::patch means you can't do something like this: notmuch show --format=mbox tag:notmuch::patch and not tag:notmuch::applied | git am which would in my opinion be a shame. > Since we don't have thread tagging yet (where e.g. tags are > automagically applied to new messages I was thinking it might work have > a tag like "notmuch::todo" and something like the following workflow > (for patches) I'm not sure why this is needed, since it seems to me that the whole argument for tagging entire threads is that the individual messages are *not* distinguishable from the thread. > initially tag +notmuch::patch +notmuch::todo > > then when we "dispose" of the patch somehow, remove the notmuch::todo tag and > replace with > notmuch::pushed > notmuch::obsolete > or... Please do *not* remove the ::patch tag. There is really no reason to. The message still contain a patch whether or not it is applied upstream. I really think this is important. The addition of something From a set of "resolution" tags (::pushed, ::applied, ::obsolete, ::rejected, etc.) should indicate resolution of the issue. jamie. pgpeVrE3buAaV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Patch review/application process
On Tue, 01 Nov 2011 14:27:53 -0700, Jameson Graef Rollins wrote: > I'm not sure why this is needed, since it seems to me that the whole > argument for tagging entire threads is that the individual messages are > *not* distinguishable from the thread. The problem is that "notmuch search foo and not bar" will return all threads containing a message satisfying "foo" and a message satisfying "not bar". This makes notmuch search tag:notmuch::patch and not notmuch::pushed notmuch use. > Please do *not* remove the ::patch tag. No, I don't suggest/intend to remove the ::patch tag, only a ::unresolved tag, since there seems to be no nice way to search for (not notmuch::resolved). > The addition of something > From a set of "resolution" tags (::pushed, ::applied, ::obsolete, > ::rejected, etc.) should indicate resolution of the issue. Here I think we agree. pgpRgycjEPEYQ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Patch review/application process
On Tue, 01 Nov 2011 20:22:58 -0300, David Bremner wrote: > The problem is that "notmuch search foo and not bar" will return all > threads containing a message satisfying "foo" and a message satisfying > "not bar". This makes > > notmuch search tag:notmuch::patch and not notmuch::pushed > > notmuch use. Actually, I don't think that's true. Notmuch will only return threads that contain individual messages that satisfy the given search term. I actually just verified this to make sure. > > Please do *not* remove the ::patch tag. > > No, I don't suggest/intend to remove the ::patch tag, only a ::unresolved tag, > since there seems to be no nice way to search for (not notmuch::resolved). We could just have a notmuch::resolved tag, which would make that easy. The we could have additional tags to indicate how it was resolved, if necessary. But honestly I really think that for most effectiveness we should keep the tag space as small as possible. I think this is going to be basically impossible, and that things are going to get confusing quickly (I think this is one of the problems with tagging in general) but I still think we should try. jamie. pgpJqdDfUjecT.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC PATCH v2 0/3] lib/cli/emacs: limit number of messages in search results
On Mon, 31 Oct 2011 14:44:29 -0700, Jameson Graef Rollins wrote: > Hi, Jani. Thanks for working on this. This should also be valuable for > vim users. Thanks for your interest! :) > In order to push forward with this, though, I think we really need to > have a complete unit test for this new functionality. We usually like > to see units tests that describe and then test for the new functionality > you wish to add, followed by the patches that provide the new > functionality. Lots of good tests for new functionality being proposed > here shouldn't be too difficult to work out ahead of time. Right. I'd just like to make sure the approach I've taken (particularly patch 1 in the set as it touches the lib) is acceptable before spending time on testing and documentation etc. Indeed patches 1 and 2 changed fundamentally between v1 and v2 after some chats on IRC. If the comments now are favourable, I'll write the tests and documentation. (Though I guess I have to admit the tests would've been beneficial to me already now...) BR, Jani.
[RFC PATCH v2 0/3] lib/cli/emacs: limit number of messages in search results
On Mon, 31 Oct 2011 23:18:07 +0200, Jani Nikula wrote: > > I'm still marking it as RFC. It works for me, but patch 1 might be deemed > unacceptable. > Hi Jani; Is just because it add a function to the library that you think this might be problematic? I don't think we are super-dogmatic about the library never growing. When notmuch started, there were no bindings, so in retrospect maybe more functionality went into the CLI than might happen if we started from scratch. If I remember Carl's statement correctly, one rule is that stuff in the library should not require configuration. Just my personal view, David
Displaying tags with many messages very slow in Emacs
On 2011, Oct 31, at 19:25 , Daniel Schoepe wrote: > On Mon, 31 Oct 2011 16:43:22 +0100, bnt wrote: >> I am not too proficient with the patch utility. Is there some kind of >> scheduled git commits timeline? > > Unfortunately, there's a huge number of outstanding patches at the > moment, so it's impossible to say when/if it will be applied. > >> If not, I guess it will be a good time to learn patching. > > There's no need to use the patch binary directly when the patches are > sent in a format git understands, which is generally the case here. To > apply patches from a thread, you can use `git am patches.mbox' where > patches.mbox contains the mails with the patches. > > If you're using the emacs UI for notmuch, you can open only those > messages with the patches you want in a thread and pipe them to an mbox > file like this: > > C-u | cat > ~/patches.mbox > > If there are no conflicts due to more recent changes to the repository, > git am patches.mbox will apply them using the commit messages from the > mails. > > FWIW: There's another more recent series of patches that accomplishes a > similar goal: id:"cover.1319833617.git.jani at nikula.org" > > Cheers, > Daniel Thank you so much for the explanation, and thanks to Jani for those patches. I will work my way into applying them. As just a plain user, I was wondering if it would be possible to have a "dev" or "untested" branch in the git repo, where one could just get all the latest patches? Of course it would not be desirable if it would just complicate the developers life. Thank you so much once again, Sam
Patch review/application process
On Tue, 25 Oct 2011 22:42:33 +0200, Daniel Schoepe wrote: >. There is also a number of patches that have been reviewed by > long-term contributors, but are then seemingly forgotten (I can find > some concrete examples of this, if this claim is in doubt). Maybe you can tag those patches as "notmuch::reviewed" using nmbug? [1] My idea is that notmuch search tag:notmuch::patch and tag:notmuch::reviewed should give a kind of consensus set of "ready to go" patch sets. Don't worry about if I or someone else disagrees with your assessment, we can always untag it, and leave a comment in the commit log. [2] There are also plenty of patches that are not reviewed at all. I'm not defending the state of patch integration, but I think we could use some more reviews as well. d [1]: http://notmuchmail.org/nmbug/ [2]: nmbug log $id could be defined as something like "cd $HOME/.nmbug && git log -- tags/$(echo $id | sha1sum -)" -- 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/2001/a3f1a86e/attachment.pgp>
Patch review/application process
On Tue, 01 Nov 2011 11:28:45 -0300, David Bremner wrote: > Maybe you can tag those patches as "notmuch::reviewed" using nmbug? [1] > My idea is that > >notmuch search tag:notmuch::patch and tag:notmuch::reviewed > > should give a kind of consensus set of "ready to go" patch sets. Don't forget notmuch::applied, which I think is actually one of the most important. Review is easy to see by looking at the patch thread. Being able to easily find which patches have not yet been applied to master is what I'm most looking forward to. 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/2001/7b32ebeb/attachment.pgp>
set test prereqs (Emacs, GDB, GPG) v4
Rebased to current master. Previous version: id:"1307016220-17509-1-git-send-email-pieter at praet.org" Discussion: id:"1317660447-27520-1-git-send-email-schnouki at schnouki.net"
[PATCH 1/4] test: add 'GnuPG' prereq to dependent 'crypto' tests
Adds a new test that checks for the presence of 'gpg',
and adds that test as a prereq to all subsequent tests
that rely on GnuPG.
This causes tests with unmet dependencies to be skipped.
---
test/crypto | 33 +++--
1 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/test/crypto b/test/crypto
index 0af4aa8..3795926 100755
--- a/test/crypto
+++ b/test/crypto
@@ -7,6 +7,11 @@
test_description='PGP/MIME signature verification and decryption'
. ./test-lib.sh
+# GnuPG is a prereq.
+test_expect_success "prereq: GnuPG is present" "which gpg" \
+&& test_set_prereq GPG
+
+
add_gnupg_home ()
{
local output
@@ -31,7 +36,7 @@ FINGERPRINT=$(gpg --no-tty --list-secret-keys --with-colons
--fingerprint | grep
# although I can't figure out why
add_email_corpus
-test_expect_success 'emacs delivery of signed message' \
+test_expect_success GPG 'emacs delivery of signed message' \
'emacs_deliver_message \
"test signed message 001" \
"This is a test signed message." \
@@ -64,7 +69,7 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/pgp-signature"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
@@ -99,7 +104,7 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/pgp-signature"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
@@ -132,7 +137,7 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/pgp-signature"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
mv "${GNUPGHOME}"{.bak,}
@@ -141,7 +146,7 @@ mv "${GNUPGHOME}"{.bak,}
cat OUTPUT
-test_expect_equal_file OUTPUT TESTATTACHMENT
+test_expect_equal_file GPG OUTPUT TESTATTACHMENT
test_begin_subtest "decryption failure with missing key"
mv "${GNUPGHOME}"{,.bak}
@@ -258,12 +263,12 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/octet-stream"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
mv "${GNUPGHOME}"{.bak,}
-test_expect_success 'emacs delivery of encrypted + signed message' \
+test_expect_success GPG 'emacs delivery of encrypted + signed message' \
'emacs_deliver_message \
"test encrypted message 002" \
"This is another test encrypted message.\n" \
@@ -298,7 +303,7 @@ expected='[[[{"id": "X",
"content-type": "text/plain",
"content": "This is another test encrypted message.\n"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
@@ -310,7 +315,7 @@ Subject: Re: test encrypted message 002
On 01 Jan 2000 12:00:00 -, Notmuch Test Suite wrote:
> This is another test encrypted message.'
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
@@ -351,7 +356,7 @@ expected='[[[{"id": "X",
{"id": 3,
"content-type": "application/pgp-signature"}]}]},
['
-test_expect_equal \
+test_expect_equal GPG \
"$output" \
"$expected"
--
1.7.7.1
[PATCH 2/4] test: add 'Emacs' prereq to dependent 'crypto' tests
Adds a new test that checks for the presence of 'emacs',
and adds that test as a prereq to all subsequent tests
that rely on Emacs.
This causes tests with unmet dependencies to be skipped.
---
test/crypto | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/test/crypto b/test/crypto
index 3795926..4a00c00 100755
--- a/test/crypto
+++ b/test/crypto
@@ -7,10 +7,21 @@
test_description='PGP/MIME signature verification and decryption'
. ./test-lib.sh
+# Emacs is a prereq.
+test_expect_success "prereq: Emacs is present" "which emacs" \
+&& test_set_prereq EMACS
+
# GnuPG is a prereq.
test_expect_success "prereq: GnuPG is present" "which gpg" \
&& test_set_prereq GPG
+# Some tests have multiple prereqs, but the test_expect_* functions
+# accept only a single argument as prereq tag, and using test_have_prereq
+# in and around tests causes various errors for me, so a dirty workaround
+# will have to do for the time being.
+test_have_prereq EMACS && test_have_prereq GPG \
+&& test_set_prereq EMACS+GPG
+
add_gnupg_home ()
{
@@ -36,7 +47,7 @@ FINGERPRINT=$(gpg --no-tty --list-secret-keys --with-colons
--fingerprint | grep
# although I can't figure out why
add_email_corpus
-test_expect_success GPG 'emacs delivery of signed message' \
+test_expect_success EMACS+GPG 'emacs delivery of signed message' \
'emacs_deliver_message \
"test signed message 001" \
"This is a test signed message." \
@@ -146,7 +157,7 @@ mv "${GNUPGHOME}"{.bak,}
cat
[PATCH 3/4] test: add 'Emacs' prereq to dependent 'emacs' tests
Adds a new test that checks for the presence of 'emacs',
and adds that test as a prereq to all subsequent tests
that rely on Emacs.
This causes tests with unmet dependencies to be skipped.
---
test/emacs | 65 ---
1 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/test/emacs b/test/emacs
index 0303d7d..8b1e5e4 100755
--- a/test/emacs
+++ b/test/emacs
@@ -3,6 +3,11 @@
test_description="emacs interface"
. test-lib.sh
+# Emacs is a prereq.
+test_expect_success "prereq: Emacs is present" "which emacs" \
+&& test_set_prereq EMACS
+
+
EXPECTED=$TEST_DIRECTORY/emacs.expected-output
add_email_corpus
@@ -10,7 +15,7 @@ add_email_corpus
test_begin_subtest "Basic notmuch-hello view in emacs"
test_emacs '(notmuch-hello)
(test-output)'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-hello
test_begin_subtest "Saved search with 0 results"
test_emacs '(let ((notmuch-show-empty-saved-searches t)
@@ -20,20 +25,20 @@ test_emacs '(let ((notmuch-show-empty-saved-searches t)
("empty" . "tag:doesnotexist"
(notmuch-hello)
(test-output))'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-hello-with-empty
test_begin_subtest "No saved searches displayed (all with 0 results)"
test_emacs '(let ((notmuch-saved-searches
'\''(("empty" . "tag:doesnotexist"
(notmuch-hello)
(test-output))'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-no-saved-searches
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-hello-no-saved-searches
test_begin_subtest "Basic notmuch-search view in emacs"
test_emacs '(notmuch-search "tag:inbox")
(notmuch-test-wait)
(test-output)'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-search-tag-inbox
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-search-tag-inbox
test_begin_subtest "Navigation of notmuch-hello to search results"
test_emacs '(notmuch-hello)
@@ -42,13 +47,13 @@ test_emacs '(notmuch-hello)
(widget-button-press (point))
(notmuch-test-wait)
(test-output)'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-view-inbox
+test_expect_equal_file EMACS OUTPUT $EXPECTED/notmuch-hello-view-inbox
test_begin_subtest "Basic notmuch-show view in emacs"
maildir_storage_thread=$(notmuch search --output=threads
id:20091117190054.GU3165 at dottiness.seas.harvard.edu)
test_emacs "(notmuch-show \"$maildir_storage_thread\")
(test-output)"
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
+test_expect_equal_file EMACS OUTPUT
$EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "notmuch-show for message with invalid From"
add_message "[subject]=\"message-with-invalid-from\"" \
@@ -64,7 +69,7 @@ Date: Tue, 05 Jan 2001 15:43:57 -
This is just a test message (#1)
EOF
-test_expect_equal_file OUTPUT EXPECTED
+test_expect_equal_file EMACS OUTPUT EXPECTED
test_begin_subtest "Navigation of notmuch-search to thread view"
test_emacs '(notmuch-search "tag:inbox")
@@ -74,7 +79,7 @@ test_emacs '(notmuch-search "tag:inbox")
(notmuch-search-show-thread)
(notmuch-test-wait)
(test-output)'
-test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
+test_expect_equal_file EMACS OUTPUT
$EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "Add tag from search view"
os_x_darwin_thread=$(notmuch search --output=threads
id:ddd65cda0911171950o4eea4389v86de9525e46052d3 at mail.gmail.com)
@@ -82,26 +87,26 @@ test_emacs "(notmuch-search \"$os_x_darwin_thread\")
(notmuch-test-wait)
(notmuch-search-add-tag \"tag-from-search-view\")"
output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
-test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
tag-from-search-view unread)"
+test_expect_equal EMACS "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
tag-from-search-view unread)"
test_begin_subtest "Remove tag from search view"
test_emacs "(notmuch-search \"$os_x_darwin_thread\")
(notmuch-test-wait)
(notmuch-search-remove-tag \"tag-from-search-view\")"
output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
-test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
unread)"
+test_expect_equal EMACS "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
unread)"
test_be
[PATCH 4/4] test: add 'Emacs' prereq to dependent 'emacs-large-search-buffer' tests
Adds a new test that checks for the presence of 'emacs', and adds that test as a prereq to all subsequent tests that rely on Emacs. This causes tests with unmet dependencies to be skipped. --- test/emacs-large-search-buffer |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/test/emacs-large-search-buffer b/test/emacs-large-search-buffer index 6095e9d..5757380 100755 --- a/test/emacs-large-search-buffer +++ b/test/emacs-large-search-buffer @@ -2,6 +2,11 @@ test_description="Emacs with large search results buffer" . test-lib.sh +# Emacs is a prereq. +test_expect_success "prereq: Emacs is present" "which emacs" \ +&& test_set_prereq EMACS + + x=xx # 10 x=$x$x$x$x$x$x$x$x$x$x # 100 x=$x$x$x$x$x$x$x$x$x # 900 @@ -27,7 +32,7 @@ test_emacs '(notmuch-search "*") (notmuch-test-wait) (test-output)' sed -i -e s', *, ,g' -e 's/xxx*/[BLOB]/g' OUTPUT -test_expect_equal_file OUTPUT EXPEXTED +test_expect_equal_file EMACS OUTPUT EXPEXTED test_begin_subtest "Ensure that emacs doesn't drop error messages" test_emacs '(notmuch-search "--this-option-does-not-exist") @@ -38,6 +43,6 @@ Error: Unexpected output from notmuch search: Unrecognized option: --this-option-does-not-exist End of search results. (process returned 1) EOF -test_expect_equal_file OUTPUT EXPEXTED +test_expect_equal_file EMACS OUTPUT EXPEXTED test_done -- 1.7.7.1
[PATCH 00/13] Test prereqs and screen-based Emacs tests
On Mon, 3 Oct 2011 18:47:14 +0200, Thomas Jost
wrote:
> Here it is: a rebased version of Pieter's patch series adding prereqs for the
> emacs and crypto tests [1], and Dmitry's patches for running emacs inside
> screen
> in the test suite [2]. (Please note that this one also includes fixes to
> improve
> hidden signatures handling in notmuch-show-advance-and-archive.)
>
I'm pleased to see these patches haven't moved to binary oblivion yet!
> I had to do several changes to the original patches:
> - prereqs are not tested using test_expect_success as they were in Pieter's
> original patches, but using a new function called test_set_bin_prereq. I
> wrote
> this before the gdb prereq was added, hence the different way to set it.
>
Indeed preferrable to using `test_expect_success' due to no longer
overzealously reporting missing prereqs as failures, as well as getting
rid of some duplication; This should also be used in the atomicity tests.
> - some fixes in Pieter's patches so that it actually works when gpg is not
> installed. Can't exactly remember what (...but you can just check his
> original
> patches), but in the end it was working fine in a chroot without gpg.
>
Correct. I only added prereqs to actual tests (i.e. calls to
`test_expect_success', `test_expect_equal', and
`test_expect_equal_file'), while they should also have been added to
both the `add_gnupg_home' function and the initialization of
${FINGERPRINT}.
> - I added a little patch to smtp-dummy that makes the test suite work again in
> Emacs 24 (tested with emacs-pretest 24.0.90).
>
> Here are the results when running the test suite on my computer:
> - without GNU Screen:
> All 247 tests behaved as expected (1 expected failure).
> 46 tests skipped.
> - with GNU Screen:
> 242/247 tests passed.
> 2 broken tests failed as expected.
> 3 tests failed.
>
> (The 3 failed tests come from some trouble with Emacs 24, I'll try to fix this
> later.)
>
> *Many* thanks to Dmitry Kurochkin and Pieter Praet for their work!
>
Thanks to you as well! All this duplication of effort is a real shame
though. I'd also have preferred your fixes being in separate commits.
I'll be commenting on these modified commits where needed, and have
re-submitted my original series (rebased to current master) in a new
thread [1].
> Regards,
> Thomas
>
> [1] id:"1307016220-17509-1-git-send-email-pieter at praet.org"
> [2] id:"1309496122-4965-1-git-send-email-dmitry.kurochkin at gmail.com"
>
> Dmitry Kurochkin (7):
> test: run emacs inside screen
> test: avoid using screen(1) configuration files
> test: do not set frame width in emacs
> test: `notmuch-show-advance-and-archive' with invisible signature
> emacs: improve hidden signatures handling in
> notmuch-show-advance-and-archive
> emacs: remove no longer used functions from notmuch-show.el
> emacs: remove unused `point-invisible-p' function
>
> Pieter Praet (4):
> test: add 'GnuPG' prereq to dependent 'crypto' tests
> test: add 'Emacs' prereq to dependent 'crypto' tests
> test: add 'Emacs' prereq to dependent 'emacs' tests
> test: add 'Emacs' prereq to dependent 'emacs-large-search-buffer'
> tests
>
> Thomas Jost (2):
> test: define a helper function for defining prereqs on executables
> test: make smtp-dummy work with Emacs 24
>
> emacs/notmuch-lib.el | 15 ---
> emacs/notmuch-show.el | 25 ---
> test/crypto| 46 ++---
> test/emacs | 85 ---
> test/emacs-large-search-buffer |9 +++-
> test/smtp-dummy.c |2 +-
> test/test-lib.el |3 -
> test/test-lib.sh | 31 +--
> 8 files changed, 127 insertions(+), 89 deletions(-)
>
> --
> 1.7.6.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Peace
--
Pieter
[1] id:"1320176954-4897-1-git-send-email-pieter at praet.org"
Patch review/application process
On Tue, 01 Nov 2011 08:55:09 -0700, Jameson Graef Rollins wrote: > On Tue, 01 Nov 2011 11:28:45 -0300, David Bremner > wrote: > > Maybe you can tag those patches as "notmuch::reviewed" using nmbug? [1] > > My idea is that > > > >notmuch search tag:notmuch::patch and tag:notmuch::reviewed > > > > should give a kind of consensus set of "ready to go" patch sets. > > Don't forget notmuch::applied, which I think is actually one of the most > important. Review is easy to see by looking at the patch thread. Being > able to easily find which patches have not yet been applied to master is > what I'm most looking forward to. Jamie knows this from IRC, but I have been using "notmuch::pushed" for this. One thing I think we need to clarify a bit is are we tagging whole threads or individual messages in the database. Because of the way notmuch search works, I had been tagging whole threads with notmuch::pushed (effectively to "mute" them) in the search notmuch search tag:notmuch::patch and \ not tag:notmuch::pushed This is a bit aesthetically unappealing, anad every time someone replies to a thread it is effectively unmuted. Since we don't have thread tagging yet (where e.g. tags are automagically applied to new messages I was thinking it might work have a tag like "notmuch::todo" and something like the following workflow (for patches) initially tag +notmuch::patch +notmuch::todo then when we "dispose" of the patch somehow, remove the notmuch::todo tag and replace with notmuch::pushed notmuch::obsolete or... Then we could do e.g. notmuch search tag:notmuch::patch and tag:notmuch::todo and tag:notmuch::reviewed to get an "integrators queue" (Well, the more like an unordered pile than a queue. One problem at a time). 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/2001/02ba5282/attachment.pgp>
[PATCH 03/13] test: add 'Emacs' prereq to dependent 'crypto' tests
On Mon, 3 Oct 2011 18:47:17 +0200, Thomas Jost wrote: > [...] The SCREEN prereq would preferrably be added in a separate commit. Also, you appear to have given *every* test the EMACS+GPG prereq, while only the ones using `emacs_deliver_message' require EMACS. Peace -- Pieter
[PATCH 04/13] test: add 'Emacs' prereq to dependent 'emacs' tests
On Mon, 3 Oct 2011 18:47:18 +0200, Thomas Jost wrote: > [...] Nice catches @ - "Sending a message via (fake) SMTP" - "Hiding message following HTML part" (though I think the latter test wasn't there yet when I submitted my patch series) New "issues": - The SCREEN prereq would preferrably be added in a separate commit. - @ "Verify that sent messages are saved/searchable (via FCC)": This doesn't need an EMACS prereq. - @ "Reply within emacs": `sed' will want to treat "EMACS" as an input file, so I think you meant to do this: test_have_prereq EMACS \ && sed -i -e 's/^In-Reply-To: <.*>$/In-Reply-To: /' OUTPUT Peace -- Pieter
[PATCH] emacs: logically group def{custom,face}s
On Tue, 18 Oct 2011 08:18:18 -0700, Jameson Graef Rollins wrote: > On Mon, 10 Oct 2011 15:49:03 +0200, Daniel Schoepe > wrote: > > On Tue, 5 Jul 2011 20:33:00 +0200, Pieter Praet > > wrote: > > > To allow for expansion whilst keeping everything tidy and organized, > > > move all defcustom/defface variables to the following subgroups, > > > defined in notmuch-lib.el: > > > > Since the customize page for notmuch is getting pretty crowded, I think > > this patch is a good idea and should be applied. > > Agreed. > > jamie. Thanks for testing, Daniel and Jameson! It still applies cleanly, so if there's anything preventing it from being merged in, I'd like to hear about it. Peace -- Pieter
[PATCH 04/13] test: add 'Emacs' prereq to dependent 'emacs' tests
On Tue, 01 Nov 2011 20:57:59 +0100, Pieter Praet wrote: > On Mon, 3 Oct 2011 18:47:18 +0200, Thomas Jost > wrote: > [...] > - @ "Verify that sent messages are saved/searchable (via FCC)": > > This doesn't need an EMACS prereq. > [...] My mistake, scrap this one. Without Emacs, there wouldn't be a sent message to begin with, so the prereq is valid. Peace -- Pieter
[PATCH 03/13] test: add 'Emacs' prereq to dependent 'crypto' tests
On Tue, 01 Nov 2011 20:56:17 +0100, Pieter Praet wrote: > On Mon, 3 Oct 2011 18:47:17 +0200, Thomas Jost > wrote: > [...] > > Also, you appear to have given *every* test the EMACS+GPG prereq, > while only the ones using `emacs_deliver_message' require EMACS. > > [...] Again, my mistake. All subsequent tests appear to be using the message sent using Emacs (is this a good idea?), so the new prereqs are valid. Peace -- Pieter
set test prereqs (Emacs, GDB, GPG) v4
On Tue, Nov 01, 2011 at 08:49:10PM +0100, Pieter Praet wrote: >Rebased to current master. > >Previous version: > id:"1307016220-17509-1-git-send-email-pieter at praet.org" > >Discussion: > id:"1317660447-27520-1-git-send-email-schnouki at schnouki.net" > Thanks for the nice work! I want to share one thing which came up to my mind during reading through them. Since we require bash for tests, we might go for using bash's builtin 'type -P foo' instead of 'which foo'. Not that it's important, just wondered "why not?" -alip -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/2001/bfaa19ca/attachment-0001.pgp>
[PATCH 1/4] test: add 'GnuPG' prereq to dependent 'crypto' tests
On Tue, 1 Nov 2011 20:49:11 +0100, Pieter Praet wrote: > -test_expect_success 'emacs delivery of signed message' \ > +test_expect_success GPG 'emacs delivery of signed message' \ Hi, Pieter and Thomas. Thanks for all the work on this, but I have one issue. Is there a way we can do this without adding a new argument to every test function? For some reason I really don't like that solution. It seems too invasive. Can't we have something that works more like test_subtest_known_broken, that modifies the test environment, rather than add an argument to every call of every testing function? 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/2001/5b88e7b1/attachment.pgp>
Patch review/application process
On Tue, 01 Nov 2011 16:55:03 -0300, David Bremner wrote: > One thing I think we need to clarify a bit is are we tagging whole > threads or individual messages in the database. Because of the way > notmuch search works, I had been tagging whole threads with > notmuch::pushed (effectively to "mute" them) in the search > > notmuch search tag:notmuch::patch and \ > not tag:notmuch::pushed > > This is a bit aesthetically unappealing, anad every time someone replies > to a thread it is effectively unmuted. I have to say that I am very much against tagging threads with tags that are really only applicable to specific messages, ie. ::patch, ::pushed (I prefer ::applied, but whatever), etc. For instance, a thread maybe contain multiple patches, but it is not itself a patch. Tagging entire threads as ::patch means you can't do something like this: notmuch show --format=mbox tag:notmuch::patch and not tag:notmuch::applied | git am which would in my opinion be a shame. > Since we don't have thread tagging yet (where e.g. tags are > automagically applied to new messages I was thinking it might work have > a tag like "notmuch::todo" and something like the following workflow > (for patches) I'm not sure why this is needed, since it seems to me that the whole argument for tagging entire threads is that the individual messages are *not* distinguishable from the thread. > initially tag +notmuch::patch +notmuch::todo > > then when we "dispose" of the patch somehow, remove the notmuch::todo tag and > replace with > notmuch::pushed > notmuch::obsolete > or... Please do *not* remove the ::patch tag. There is really no reason to. The message still contain a patch whether or not it is applied upstream. I really think this is important. The addition of something
Patch review/application process
On Tue, 01 Nov 2011 14:27:53 -0700, Jameson Graef Rollins wrote: > I'm not sure why this is needed, since it seems to me that the whole > argument for tagging entire threads is that the individual messages are > *not* distinguishable from the thread. The problem is that "notmuch search foo and not bar" will return all threads containing a message satisfying "foo" and a message satisfying "not bar". This makes notmuch search tag:notmuch::patch and not notmuch::pushed notmuch use. > Please do *not* remove the ::patch tag. No, I don't suggest/intend to remove the ::patch tag, only a ::unresolved tag, since there seems to be no nice way to search for (not notmuch::resolved). > The addition of something > From a set of "resolution" tags (::pushed, ::applied, ::obsolete, > ::rejected, etc.) should indicate resolution of the issue. Here I think we agree. -- 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/2001/b42c4053/attachment.pgp>
Patch review/application process
On Tue, 01 Nov 2011 20:22:58 -0300, David Bremner wrote: > The problem is that "notmuch search foo and not bar" will return all > threads containing a message satisfying "foo" and a message satisfying > "not bar". This makes > > notmuch search tag:notmuch::patch and not notmuch::pushed > > notmuch use. Actually, I don't think that's true. Notmuch will only return threads that contain individual messages that satisfy the given search term. I actually just verified this to make sure. > > Please do *not* remove the ::patch tag. > > No, I don't suggest/intend to remove the ::patch tag, only a ::unresolved tag, > since there seems to be no nice way to search for (not notmuch::resolved). We could just have a notmuch::resolved tag, which would make that easy. The we could have additional tags to indicate how it was resolved, if necessary. But honestly I really think that for most effectiveness we should keep the tag space as small as possible. I think this is going to be basically impossible, and that things are going to get confusing quickly (I think this is one of the problems with tagging in general) but I still think we should try. 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/2001/543f2f66/attachment.pgp>
