[PATCH 2/2] test: use emacsclient(1) for Emacs tests
Quoth Dmitry Kurochkin on Jun 28 at 5:03 am:
> > > The only way I know to
> > > reliably kill a child process is to open a pipe to it and have it exit
> > > on its own when it reads EOF. Unfortunately, I couldn't find a way to
> > > do this with an emacs daemon (it appears daemon mode aggressively
> > > cleans up things like pipes), but here's a different approach:
> > >
> > > coproc emacs --batch --eval "(while t (eval (read)))"
> > > EMACSFD=${COPROC[1]}
> > > trap "echo '(kill-emacs)' >&$EMACSFD" EXIT
> > >
> > > echo '(message "Hi")' >&$EMACSFD
> > > # ...
> > >
> > > This is, basically, a poor man's emacs server, but the coprocess pipe
> > > binds it tightly to the shell. If the shell exits for *any* reason,
> > > the pipe will be closed by the kernel, emacs will read an EOF, and
> > > exit.
> >
> > I like this idea.
> >
> > > The trap is there just to cleanly shut down in case of a normal
> > > exit [1].
> >
> > For normal exit we should just put this into test_done. Otherwise it is
> > not a normal exit and we do not care about Emacs error message. No?
> >
> > > This also has the advantage that read-from-minibuffer still
> > > works:
> > >
> > > echo '(message (read-from-minibuffer ""))' >&$EMACSFD
> > > echo 'Test' >&$EMACSFD
> > >
> > > Thoughts?
> > >
> >
> > I like it and I will implement it. Thanks for the idea.
> >
>
> While implementing the idea, I stumbled upon a problem: we need to know
> when Emacs finished what we echoed or failed with an error. At the
> moment tests fail because they check for OUTPUT before Emacs creates it.
>
> We can tell Emacs to print some special marker and wait for it. But
> there may be exceptions and errors which may make it difficult. I did
> not found a good solution yet. Would love to hear your thoughts :)
Oof, yes, of course. How about making the one-line poor man's emacs
server slightly less poor? Use a FIFO to communicate completion.
Something like,
EMACSDONE=$TEST_DIRECTORY/emacsdone
mkfifo $EMACSDONE
coproc emacs --batch --eval '(while t (eval (read)) (write-region "\n" nil
"'$EMACSDONE'" t 0))'
EMACSFD=${COPROC[1]}
test_emacs() {
echo "$1" >&$EMACSFD
read <$EMACSDONE
}
test_emacs '(sleep-for 2)'
test_emacs '(message "Hi")'
echo '(kill-emacs)' >&$EMACSFD
Re: Race condition for '*' command
On Sun, 26 Jun 2011 10:00:41 +0100, Robin Green wrote:
> On Sat, 25 Jun 2011 16:57:50 -0700, Jameson Graef Rollins
> wrote:
> > On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green wrote:
> > > A race condition in the '*' command was noted when it was first
> > > proposed. It looks to me like it still exists - has anything been done
> > > about it?
> >
> > Hi, Robin. Can you explain what you mean by the "'*' command"?
>
> Sorry - forgot to say I'm talking about the notmuch emacs mode. In that
> mode '*' applies tags to all messages matching the current search query,
> which means that (here's the race condition) new results that have
> appeared since the last refresh will also be tagged.
This issue appears to stem from the fact that `notmuch-search-operate-all'
runs (apply 'notmuch-tag notmuch-search-query-string action-split), in which
`notmuch-search-query-string' points to a moving target.
Could be solved by doing it with `notmuch-search', `mark-whole-buffer'
and `notmuch-search-{add,remove}-tag-region' instead, but I'm sure
there's a better way (of which I'm as of yet unaware).
> --
> Robin
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Peace
--
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test:Folder tags shouldn't match after removal of file in given folder
On Mon, 27 Jun 2011 11:12:24 -0600, Mark Anderson wrote:
>
> Test for bug. Current stemming support for notmuch adds extra terms
> to the DB which aren't removed when the file renames are detected.
>
> When folder tags are added to a message, Xapian terms for both XFOLDER
> and ZXFOLDER are generated. When one of the filenames are
> renamed/removed, only the XFOLDER tags are removed, leaving it possible
> for a match on a folder: tag that was previously but is no longer a
> match in the maildir.
> ---
>
> I found this bug last week. Essentially when the folder:spam tag is
> added and puts the XFOLDERspam, it also inserts the ZXFOLDERspam. Then
> if the mail is removed from the folder, it neglects to remove
> ZXFOLDERspam.
>
> This was detected with my offlineimap usage with gmail, still haven't
> polished my personal folder/label transition. As I was looking into it,
> I saw some unusual things flagged as spam, and investigated.
+1
This bug was reported by Sebastian back in January [1], and I
submitted a test [2], but yours is much more thorough, both
regarding the actual test as well as the commit message.
I'd forgotten all about this issue myself, so it's very nice
to see it brought up again.
Thanks!
>
> test/notmuch-test|1 +
> test/search-folder-coherence | 48
> ++
> 2 files changed, 49 insertions(+), 0 deletions(-)
> create mode 100755 test/search-folder-coherence
>
> diff --git a/test/notmuch-test b/test/notmuch-test
> index fe85c6a..79e6267 100755
> --- a/test/notmuch-test
> +++ b/test/notmuch-test
> @@ -41,6 +41,7 @@ TESTS="
>maildir-sync
>crypto
>symbol-hiding
> + search-folder-coherence
> "
> TESTS=${NOTMUCH_TESTS:=$TESTS}
>
> diff --git a/test/search-folder-coherence b/test/search-folder-coherence
> new file mode 100755
> index 000..cf3ba40
> --- /dev/null
> +++ b/test/search-folder-coherence
> @@ -0,0 +1,48 @@
> +#!/usr/bin/env bash
> +test_description='folder tags removed and added through file renames remain
> consistent'
> +. ./test-lib.sh
> +
> +test_begin_subtest "No new messages"
> +output=$(NOTMUCH_NEW)
> +test_expect_equal "$output" "No new mail."
> +
> +
> +test_begin_subtest "Single new message"
> +generate_message
> +file_x=$gen_msg_filename
> +id_x=$gen_msg_id
> +output=$(NOTMUCH_NEW)
> +test_expect_equal "$output" "Added 1 new message to the database."
> +
> +test_begin_subtest "Add second folder for same message"
> +dir=$(dirname $file_x)
> +mkdir $dir/spam
> +cp $file_x $dir/spam
> +output=$(NOTMUCH_NEW)
> +test_expect_equal "$output" "No new mail."
> +
> +
> +test_begin_subtest "Multiple files for same message"
> +cat +MAIL_DIR/msg-001
> +MAIL_DIR/spam/msg-001
> +EOF
> +notmuch search --output=files id:$id_x | sed -e "s,$MAIL_DIR,MAIL_DIR,"
> >OUTPUT
> +test_expect_equal_file OUTPUT EXPECTED
> +
> +test_begin_subtest "Test matches folder:spam"
> +output=$(notmuch search folder:spam)
> +test_expect_equal "$output" "thread:0001 2001-01-05 [1/1]
> Notmuch Test Suite; Test message #1 (inbox unread)"
> +
> +sleep 1;
> +
> +test_begin_subtest "Remove folder:spam copy of email"
> +rm $dir/spam/$(basename $file_x)
> +output=$(NOTMUCH_NEW)
> +test_expect_equal "$output" "No new mail. Detected 1 file rename."
> +
> +test_begin_subtest "No mails match the folder:spam search"
> +output=$(notmuch search folder:spam)
> +test_expect_equal "$output" ""
> +
> +test_done
> --
> 1.7.4.1
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Peace
--
Pieter
[1] id:"87vd1n4rd2@sspaeth.de"
[2] id:"1305270308-30660-1-git-send-email-pie...@praet.org"
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Debian package not building
On Fri, 24 Jun 2011 16:34:02 -0700, Jameson Graef Rollins wrote: Non-text part: multipart/mixed Non-text part: multipart/signed > Hey, folks. As of today I am for some reason no longer able to build > the Notmuch Debian package. I'm using the same build technique I have > been using for a while (git-buildpackage). The tail of the failing > build log is pasted at the bottom of this message. Is anyone else > encountering anything like this? > > I don't see what of the recent packaging changes, other than the RPATH > stuff, could be affecting this, and I get the same failure even if I > revert the revert of the RPATH override (ie. RPATH_LDFLAGS auto-build > override in place). I did recently do a system upgrade, so it's > possible that something there could have caused the problem. > > What could be preventing dpkg-shlibdeps from finding libpthread.so.0 or > libc.so.6? May be PKG_CONFIG_PATH related? > jamie. > > > servo:~/src/notmuch/git [master] 1$ git buildpackage -us -uc > --git-ignore-branch > ... > dpkg-shlibdeps: error: couldn't find library libpthread.so.0 needed by > debian/notmuch/usr/bin/notmuch (ELF format: 'elf64-x86-64'; RPATH: ''). > dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by > debian/notmuch/usr/bin/notmuch (ELF format: 'elf64-x86-64'; RPATH: ''). > dpkg-shlibdeps: error: Cannot continue due to the errors listed above. > Note: libraries are not searched in other binary packages that do not have > any shlibs or symbols file. > To help dpkg-shlibdeps find private libraries, you might need to set > LD_LIBRARY_PATH. > dh_shlibdeps: dpkg-shlibdeps -Tdebian/notmuch.substvars > debian/notmuch/usr/bin/notmuch returned exit code 2 > make: *** [binary] Error 2 > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status > 2 > debuild: fatal error at line 1340: > dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed > gbp:error: debuild -i -I returned 29 > gbp:error: Couldn't run 'debuild -i -I -us -uc' > servo:~/src/notmuch/git [master] 1$ Non-text part: application/pgp-signature > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test:Improve test behaviors when --root is used
On Mon, 27 Jun 2011 16:50:47 -0400, Austin Clements wrote:
> This looks great (modulo one bug, below). I've wanted to run the
> tests on tmpfs before, but was too lazy to actually fix the tests.
>
> Given how easy it is to accidentally use "..", I wonder if there's a
> way to force people to use $TEST_DIRECTORY?
Something like this? Mind you, my grep-fu is non-existent.
#+BEGIN_SRC sh
dotdot=$(rgrep -nH -e "\.\.\/" . | grep -v -e "\$TEST_DIRECTORY")
if [ -n "${dotdot}" ] ; then
echo -e "Don't dot dot me! Use \$TEST_DIRECTORY as prefix
instead.\n\nOffending lines:\n ${dotdot}"
fi
#+END_SRC
> On Mon, Jun 27, 2011 at 12:09 PM, Mark Anderson wrote:
> > --- a/test/symbol-hiding
> > +++ b/test/symbol-hiding
> > @@ -12,13 +12,13 @@ test_description='exception symbol hiding'
> > . ./test-lib.sh
> >
> > run_test(){
> > - result=$(LD_LIBRARY_PATH=../../lib ./symbol-test 2>&1)
> > + result=$(LD_LIBRARY_PATH=$TEST_DIRECTORY/../../lib ./symbol-test 2>&1)
>
> Did you mean $TEST_DIRECTORY/../lib?
> ___
> 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: Drafts being tagged as inbox
On Mon, 27 Jun 2011 22:50:25 +0100, Robin Green wrote:
> My drafts (created using emacs message mode) are being tagged as
> inbox. However, they are not tagged as drafts. This is because emacs
> message mode does not store drafts in Maildir format, so there are no
> Maildir flags (e.g. D for draft) to sync tags with.
>
> Now, I could simply store drafts somewhere else, but then I wouldn't be
> able to search them using notmuch. Is there another way to have drafts
> correctly tagged?
notmuch tag -inbox +draft -- folder:${where_your_drafts_reside}
... in your tagging script.
> Thanks,
> Robin Green
> ___
> 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
Drafts being tagged as inbox
My drafts (created using emacs message mode) are being tagged as inbox. However, they are not tagged as drafts. This is because emacs message mode does not store drafts in Maildir format, so there are no Maildir flags (e.g. D for draft) to sync tags with. Now, I could simply store drafts somewhere else, but then I wouldn't be able to search them using notmuch. Is there another way to have drafts correctly tagged? Thanks, Robin Green
interaction between --format=raw and multipart handling [was: Re: Do not attept to output part raw if part is not GMimePart.]
On Mon, Jun 27, 2011 at 6:41 PM, Daniel Kahn Gillmor wrote: > On 06/27/2011 06:07 PM, Austin Clements wrote: >> Oh, right, of course. ?show_message_part will walk into the parts, so >> format_part_content_raw will still be called on the leafs of a >> requested multipart. ?Though, this approach results in each leaf being >> transfer decoded and printed individually, so if you ask for a >> multipart, you won't get the "raw" contents of the multipart (unless >> it's part 0), so much as you get the concatenated "raw" contents of >> each part in the multipart. > > > let's take two labeled examples: > > A???multipart/signed 58292 bytes > B ???multipart/mixed 56553 bytes > C ???text/plain 1278 bytes > D ???text/plain attachment [grub-install.out] 54109 bytes > E ???text/x-diff attachment [597538.patch] 496 bytes > F ??application/pgp-signature attachment [signature.asc] 900 bytes > > > X???multipart/signed 3863 bytes > Y ??text/plain 1857 bytes > Z ??application/pgp-signature attachment [signature.asc] 900 bytes > > (i know, you won't use "A" or "Z" as part IDs once we have hierarchical > part numbers, but consider them placeholders). > > if parts F or Z are ever going to be useful (e.g. to some external > process that wants to validate the signature by hand), then the tool > needs to provide some way of producing parts B and Y in a pristine form > (that is, including MIME headers and without interpreting/applying any > transfer encodings). > > Perhaps this means there are two flavors of "raw" that we should be > distinguishing, something like: > > ?0) "source" -- the equivalent to viewing the source of the message, > with headers and without attempting to reverse transfer-encodings, etc. > > ?1) "rare" -- (not entirely raw, but still bloody, ha ha) strip headers, > reverse transfer encodings, etc. > > I think our current implementation of --format=raw emits "source" when > applied to the entire message, but "rare" when applied to one of the parts. Yes. > I'm suggesting that it might be useful to be able to get "source" of a > part. ?(and perhaps it might also be useful to get the whole message > "rare" sometimes?) > > My first instinct was: if it's multipart, provide "source", if it's > single-part, provide "rare". ?But that fails for the XYZ case above -- > we'd need Y (which is single-part) to be provided as "source" if we were > ever to be able to make use of Z on its own, so i don't think it'll be > that simple. > > OTOH, i'm not sure that "rare" is particularly meaningful for non-leaf > parts. > >> That if you ask for a multipart, you should effectively get a slice >> out of the original message bytes (since multipart/* parts can't have >> non-identity transfer encodings). ?Are you also saying that should >> extend to transfer encoded leaf parts, too? > > hmm. ?is it true that multipart/* parts can't have non-identity transfer > encodings? ?that would simplify some things, but i don't have a > reference handy that says it's the case. RFC 2045, section 6.4: "If an entity is of type "multipart" the Content-Transfer-Encoding is not permitted to have any value other than "7bit", "8bit" or "binary"." (And, for completeness, section 6.2: "The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all mean that the identity (i.e. NO) encoding transformation has been performed.") > At any rate, i'm not sure it affects the need for being able to emit > both "rare" and "source" forms of at least the leaf (non-multipart) parts. > > i hope this is all at least somewhat clarifying and not just adding to > the confusion, Thanks. That's actually very informative and solidifies some of what's been slowly coagulating in my mind. I was also thinking about the two output variants you describe (though, being less clever, I was thinking "raw" and "decoded"). The fact that multipart/* parts can only have identity encodings makes me wonder if the two could be merged by thinking of the decoded content of a leaf part as a child/body to the original, encoded part. On the other hand, that doesn't make sense for other formats, so perhaps that's not a fruitful approach.
[PATCH] test: use emacsclient(1) for Emacs tests
Before the change, every Emacs test ran in a separate Emacs
instance. Starting Emacs many times wastes considerable time and
it gets worse as the test suite grows. The patch solves this by
using a single Emacs server and emacsclient(1) to run multiple
tests. Emacs server is started on the first test_emacs call and
stopped when test_done is called. We take care not to leave
orphan Emacs processes behind when test is terminated by whatever
reason: Emacs server runs a watchdog that periodically checks
that the test is still running.
Some tests need to provide user input. Before the change, this
was done using echo(1) to Emacs stdin. This no longer works and
instead `standard-input' variable is set accordingly to make
`read' return the appropriate string.
---
Amended patch with a more appropriate Emacs server name. Sorry,
for inconvenience, should go to sleep.
Regards,
Dmitry
test/emacs | 10 +-
test/test-lib.el | 13 +
test/test-lib.sh | 24 +---
3 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/test/emacs b/test/emacs
index 3d42645..0f5f99c 100755
--- a/test/emacs
+++ b/test/emacs
@@ -259,15 +259,15 @@ test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "Save attachment from within emacs using
notmuch-show-save-attachments"
# save as archive to test that Emacs does not re-compress .gz
-echo ./attachment1.gz |
-test_emacs '(notmuch-show
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com")
- (notmuch-show-save-attachments)' > /dev/null 2>&1
+test_emacs '(let ((standard-input "\"attachment1.gz\""))
+ (notmuch-show
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com")
+ (notmuch-show-save-attachments))' > /dev/null 2>&1
test_expect_equal_file attachment1.gz "$EXPECTED/attachment"
test_begin_subtest "Save attachment from within emacs using
notmuch-show-save-part"
# save as archive to test that Emacs does not re-compress .gz
-echo ./attachment2.gz |
-test_emacs '(notmuch-show-save-part
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com" 5)' >
/dev/null 2>&1
+test_emacs '(let ((standard-input "\"attachment2.gz\""))
+ (notmuch-show-save-part
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com" 5))' >
/dev/null 2>&1
test_expect_equal_file attachment2.gz "$EXPECTED/attachment"
test_begin_subtest "View raw message within emacs"
diff --git a/test/test-lib.el b/test/test-lib.el
index 4e7f5cf..a783936 100644
--- a/test/test-lib.el
+++ b/test/test-lib.el
@@ -23,6 +23,12 @@
;; avoid crazy 10-column default of --batch
(set-frame-width (window-frame (get-buffer-window)) 80)
+;; `read-file-name' by default uses `completing-read' function to read
+;; user input. It does not respect `standard-input' variable which we
+;; use in tests to provide user input. So replace it with a plain
+;; `read' call.
+(setq read-file-name-function (lambda (&rest _) (read)))
+
(defun notmuch-test-wait ()
"Wait for process completion."
(while (get-buffer-process (current-buffer))
@@ -51,3 +57,10 @@ FILENAME is OUTPUT."
(setq str (concat str (buffer-substring start next-pos
(setq start next-pos)))
str))
+
+(defun orphan-watchdog (pid)
+ "Periodically check that the process with id PID is still
+running, quit if it terminated."
+ (if (not (process-attributes pid))
+ (kill-emacs)
+(run-at-time "1 min" nil 'orphan-watchdog pid)))
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 48bace2..bcf18ec 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -829,6 +829,8 @@ test_done () {
echo
+ [ -n "$EMACS_SERVER" ] && test_emacs '(kill-emacs)'
+
if [ "$test_failure" = "0" ]; then
if [ "$test_broken" = "0" ]; then
rm -rf "$remove_tmp"
@@ -848,16 +850,8 @@ emacs_generate_script () {
export PATH=$PATH
export NOTMUCH_CONFIG=$NOTMUCH_CONFIG
-# We assume that the user will give a command-line argument only if
-# wanting to run in batch mode.
-if [ \$# -gt 0 ]; then
- BATCH=--batch
-fi
-
# Here's what we are using here:
#
-# --batch: Quit after given commands and print all (messages)
-#
# --no-init-file Don't load users ~/.emacs
#
# --no-site-file Don't load the site-wide startup stuff
@@ -866,16 +860,24 @@ fi
#
# --load Force loading of notmuch.el and test-lib.el
-emacs \$BATCH --no-init-file --no-site-file \
+emacs --no-init-file --no-site-file \
--directory "$TMP_DIRECTORY/../../emacs" --load notmuch.el \
--directory "$TMP_DIRECTORY/.." --load test-lib.el \
- --eval "(progn \$@)"
+ "\$@"
EOF
chmod a+x "$TMP_DIRECTORY/run_emacs"
}
test_emacs () {
- "$TMP_DIRECTORY/run_emacs" "$@"
+ if [ -z "$EMACS_SERVER" ]; then
+ EMACS_SERVER="notmuch-test-suite-$$"
+ "$TMP_DIRECTORY/run_emacs" \
+ --dae
[PATCH 04/10] test: wrap and indent test_emacs calls
Most test_emacs calls have long arguments that consist of many
expressions. Putting them on a single line makes it hard to read
and produces poor diff when they are changed. The patch puts
every expression in test_emacs calls on a separate line.
---
test/emacs | 124 --
test/test-lib.sh | 14 ++-
2 files changed, 114 insertions(+), 24 deletions(-)
diff --git a/test/emacs b/test/emacs
index f4ff3f1..fddb4a1 100755
--- a/test/emacs
+++ b/test/emacs
@@ -7,32 +7,51 @@ EXPECTED=../emacs.expected-output
add_email_corpus
test_begin_subtest "Basic notmuch-hello view in emacs"
-test_emacs '(notmuch-hello) (princ (buffer-string))' >OUTPUT
+test_emacs '(notmuch-hello)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
test_begin_subtest "Saved search with 0 results"
-test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" . "tag:unread")
("empty" . "tag:doesnotexist"))) (notmuch-hello) (princ (buffer-string))'
>OUTPUT
+test_emacs '(setq notmuch-show-empty-saved-searches t)
+ (setq notmuch-saved-searches
+ '\''(("inbox" . "tag:inbox")
+ ("unread" . "tag:unread")
+ ("empty" . "tag:doesnotexist")))
+ (notmuch-hello)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
test_begin_subtest "No saved searches displayed (all with 0 results)"
-test_emacs '(setq notmuch-saved-searches '\''(("empty" . "tag:doesnotexist")))
(notmuch-hello) (princ (buffer-string))' >OUTPUT
+test_emacs '(setq notmuch-saved-searches
+ '\''(("empty" . "tag:doesnotexist")))
+ (notmuch-hello)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file 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) (princ
(buffer-string))' >OUTPUT
+test_emacs '(notmuch-search "tag:inbox")
+ (notmuch-test-wait)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file OUTPUT $EXPECTED/notmuch-search-tag-inbox
test_begin_subtest "Navigation of notmuch-hello to search results"
-test_emacs '(notmuch-hello) (goto-char (point-min)) (re-search-forward
"inbox") (widget-button-press (point)) (notmuch-test-wait) (princ
(buffer-string))' >OUTPUT
+test_emacs '(notmuch-hello)
+ (goto-char (point-min))
+ (re-search-forward "inbox")
+ (widget-button-press (point))
+ (notmuch-test-wait)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file 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\") (princ
(buffer-string))" >OUTPUT
+test_emacs "(notmuch-show \"$maildir_storage_thread\")
+ (princ (buffer-string))" >OUTPUT
test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "notmuch-show for message with invalid From"
-add_message "[subject]=\"message-with-invalid-from\"" "[from]=\"\\\"Invalid
\\\" From\\\" \""
+add_message "[subject]=\"message-with-invalid-from\"" \
+ "[from]=\"\\\"Invalid \\\" From\\\" \""
thread=$(notmuch search --output=threads subject:message-with-invalid-from)
output=$(test_emacs "(notmuch-show \"$thread\") (princ (buffer-string))")
test_expect_equal "$output" \
@@ -44,33 +63,54 @@ Date: Tue, 05 Jan 2001 15:43:57 -
This is just a test message (#1)'
test_begin_subtest "Navigation of notmuch-search to thread view"
-test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait) (goto-char
(point-min)) (re-search-forward "Working with Maildir")
(notmuch-search-show-thread) (notmuch-test-wait) (princ (buffer-string))'
>OUTPUT
+test_emacs '(notmuch-search "tag:inbox")
+ (notmuch-test-wait)
+ (goto-char (point-min))
+ (re-search-forward "Working with Maildir")
+ (notmuch-search-show-thread)
+ (notmuch-test-wait)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file 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)
-test_emacs "(notmuch-search \"$os_x_darwin_thread\") (notmuch-test-wait)
(notmuch-search-add-tag \"tag-from-search-view\")"
+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
[PATCH 10/10] test: use emacsclient(1) for Emacs tests
Before the change, every Emacs test ran in a separate Emacs
instance. Starting Emacs many times wastes considerable time and
it gets worse as the test suite grows. The patch solves this by
using a single Emacs server and emacsclient(1) to run multiple
tests. Emacs server is started on the first test_emacs call and
stopped when test_done is called. We take care not to leave
orphan Emacs processes behind when test is terminated by whatever
reason: Emacs server runs a watchdog that periodically checks
that the test is still running.
Some tests need to provide user input. Before the change, this
was done using echo(1) to Emacs stdin. This no longer works and
instead `standard-input' variable is set accordingly to make
`read' return the appropriate string.
---
test/emacs | 10 +-
test/test-lib.el | 13 +
test/test-lib.sh | 24 +---
3 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/test/emacs b/test/emacs
index 3d42645..0f5f99c 100755
--- a/test/emacs
+++ b/test/emacs
@@ -259,15 +259,15 @@ test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "Save attachment from within emacs using
notmuch-show-save-attachments"
# save as archive to test that Emacs does not re-compress .gz
-echo ./attachment1.gz |
-test_emacs '(notmuch-show
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com")
- (notmuch-show-save-attachments)' > /dev/null 2>&1
+test_emacs '(let ((standard-input "\"attachment1.gz\""))
+ (notmuch-show
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com")
+ (notmuch-show-save-attachments))' > /dev/null 2>&1
test_expect_equal_file attachment1.gz "$EXPECTED/attachment"
test_begin_subtest "Save attachment from within emacs using
notmuch-show-save-part"
# save as archive to test that Emacs does not re-compress .gz
-echo ./attachment2.gz |
-test_emacs '(notmuch-show-save-part
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com" 5)' >
/dev/null 2>&1
+test_emacs '(let ((standard-input "\"attachment2.gz\""))
+ (notmuch-show-save-part
"id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com" 5))' >
/dev/null 2>&1
test_expect_equal_file attachment2.gz "$EXPECTED/attachment"
test_begin_subtest "View raw message within emacs"
diff --git a/test/test-lib.el b/test/test-lib.el
index 4e7f5cf..a783936 100644
--- a/test/test-lib.el
+++ b/test/test-lib.el
@@ -23,6 +23,12 @@
;; avoid crazy 10-column default of --batch
(set-frame-width (window-frame (get-buffer-window)) 80)
+;; `read-file-name' by default uses `completing-read' function to read
+;; user input. It does not respect `standard-input' variable which we
+;; use in tests to provide user input. So replace it with a plain
+;; `read' call.
+(setq read-file-name-function (lambda (&rest _) (read)))
+
(defun notmuch-test-wait ()
"Wait for process completion."
(while (get-buffer-process (current-buffer))
@@ -51,3 +57,10 @@ FILENAME is OUTPUT."
(setq str (concat str (buffer-substring start next-pos
(setq start next-pos)))
str))
+
+(defun orphan-watchdog (pid)
+ "Periodically check that the process with id PID is still
+running, quit if it terminated."
+ (if (not (process-attributes pid))
+ (kill-emacs)
+(run-at-time "1 min" nil 'orphan-watchdog pid)))
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 48bace2..e8f8629 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -829,6 +829,8 @@ test_done () {
echo
+ [ -n "$EMACS_SERVER" ] && test_emacs '(kill-emacs)'
+
if [ "$test_failure" = "0" ]; then
if [ "$test_broken" = "0" ]; then
rm -rf "$remove_tmp"
@@ -848,16 +850,8 @@ emacs_generate_script () {
export PATH=$PATH
export NOTMUCH_CONFIG=$NOTMUCH_CONFIG
-# We assume that the user will give a command-line argument only if
-# wanting to run in batch mode.
-if [ \$# -gt 0 ]; then
- BATCH=--batch
-fi
-
# Here's what we are using here:
#
-# --batch: Quit after given commands and print all (messages)
-#
# --no-init-file Don't load users ~/.emacs
#
# --no-site-file Don't load the site-wide startup stuff
@@ -866,16 +860,24 @@ fi
#
# --load Force loading of notmuch.el and test-lib.el
-emacs \$BATCH --no-init-file --no-site-file \
+emacs --no-init-file --no-site-file \
--directory "$TMP_DIRECTORY/../../emacs" --load notmuch.el \
--directory "$TMP_DIRECTORY/.." --load test-lib.el \
- --eval "(progn \$@)"
+ "\$@"
EOF
chmod a+x "$TMP_DIRECTORY/run_emacs"
}
test_emacs () {
- "$TMP_DIRECTORY/run_emacs" "$@"
+ if [ -z "$EMACS_SERVER" ]; then
+ EMACS_SERVER="notmuch-server-$$"
+ "$TMP_DIRECTORY/run_emacs" \
+ --daemon \
+ --eval "(setq server-name \"$EMACS_SERVER\")" \
+ --eval "(orphan-watchdog $$
[PATCH 08/10] test: set variables using `let' instead of `setq' in Emacs tests
Using `setq' for setting variables in Emacs tests affect other
tests that may run in the same Emacs environment. Currently it
works because each test is run in a separate Emacs instance. But
in the future multiple tests will run in a single Emacs instance.
The patch changes all variables to use `let', so the scope of the
change is limited to a single test.
---
test/emacs | 70 +
test/test-lib.sh | 27 ++--
2 files changed, 52 insertions(+), 45 deletions(-)
diff --git a/test/emacs b/test/emacs
index 409e033..3d42645 100755
--- a/test/emacs
+++ b/test/emacs
@@ -1,4 +1,10 @@
#!/usr/bin/env bash
+
+# Note: do not use `setq' for setting variables in Emacs tests because
+# it affects other tests that may run in the same Emacs instance. Use
+# `let' instead so the scope of the changed variables is limited to a
+# single test.
+
test_description="emacs interface"
. test-lib.sh
@@ -12,20 +18,20 @@ test_emacs '(notmuch-hello)
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
test_begin_subtest "Saved search with 0 results"
-test_emacs '(setq notmuch-show-empty-saved-searches t)
- (setq notmuch-saved-searches
- '\''(("inbox" . "tag:inbox")
- ("unread" . "tag:unread")
- ("empty" . "tag:doesnotexist")))
- (notmuch-hello)
- (test-output)'
+test_emacs '(let ((notmuch-show-empty-saved-searches t)
+ (notmuch-saved-searches
+ '\''(("inbox" . "tag:inbox")
+ ("unread" . "tag:unread")
+ ("empty" . "tag:doesnotexist"
+ (notmuch-hello)
+ (test-output))'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
test_begin_subtest "No saved searches displayed (all with 0 results)"
-test_emacs '(setq notmuch-saved-searches
- '\''(("empty" . "tag:doesnotexist")))
- (notmuch-hello)
- (test-output)'
+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_begin_subtest "Basic notmuch-search view in emacs"
@@ -147,9 +153,9 @@ output=$(notmuch search 'subject:"testing message sent via
SMTP"' | notmuch_sear
test_expect_equal "$output" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite;
Testing message sent via SMTP (inbox)"
test_begin_subtest "notmuch-fcc-dirs set to nil"
-test_emacs "(setq notmuch-fcc-dirs nil)
- (notmuch-mua-mail)
- (test-output)"
+test_emacs "(let ((notmuch-fcc-dirs nil))
+ (notmuch-mua-mail)
+ (test-output))"
cat
[PATCH 09/10] test: generate run_emacs script once on test startup
Instead of generating auxiliary run_emacs script every time
test_emacs is run, do it once in the beginning of the test.
Also, use absolute paths in the script to make it more robust.
---
test/test-lib.sh | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 7c8a86f..48bace2 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -839,11 +839,11 @@ test_done () {
fi
}
-test_emacs () {
+emacs_generate_script () {
# Construct a little test script here for the benefit of the user,
# (who can easily run "run_emacs" to get the same emacs environment
# for investigating any failures).
- cat < run_emacs
+ cat <"$TMP_DIRECTORY/run_emacs"
#!/bin/sh
export PATH=$PATH
export NOTMUCH_CONFIG=$NOTMUCH_CONFIG
@@ -867,12 +867,15 @@ fi
# --load Force loading of notmuch.el and test-lib.el
emacs \$BATCH --no-init-file --no-site-file \
- --directory ../../emacs --load notmuch.el \
- --directory .. --load test-lib.el \
+ --directory "$TMP_DIRECTORY/../../emacs" --load notmuch.el \
+ --directory "$TMP_DIRECTORY/.." --load test-lib.el \
--eval "(progn \$@)"
EOF
- chmod a+x ./run_emacs
- ./run_emacs "$@"
+ chmod a+x "$TMP_DIRECTORY/run_emacs"
+}
+
+test_emacs () {
+ "$TMP_DIRECTORY/run_emacs" "$@"
}
@@ -1000,6 +1003,8 @@ primary_email=test_su...@notmuchmail.org
other_email=test_suite_ot...@notmuchmail.org;test_su...@otherdomain.org
EOF
+emacs_generate_script
+
# Use -P to resolve symlinks in our working directory so that the cwd
# in subprocesses like git equals our $PWD (for pathname comparisons).
--
1.7.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 07/10] test: use emacs_deliver_message in Emacs SMTP send test
Minor changes to expected results of other Emacs tests were
needed because the message Date header changed.
---
test/emacs | 34 +-
1 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/test/emacs b/test/emacs
index 4592005..409e033 100755
--- a/test/emacs
+++ b/test/emacs
@@ -118,28 +118,12 @@ output=$(notmuch search 'id:"123..456@example"' |
notmuch_search_sanitize)
test_expect_equal "$output" "thread:XXX 2001-01-05 [1/1] Notmuch Test Suite;
Message with .. in Message-Id (inbox search-add show-add)"
test_begin_subtest "Sending a message via (fake) SMTP"
-
-# Before we can send a message, we have to prepare the FCC maildir
-mkdir -p mail/sent/cur
-mkdir -p mail/sent/new
-mkdir -p mail/sent/tmp
-
-../smtp-dummy sent_message &
-smtp_dummy_pid=$!
-test_emacs "(setq message-send-mail-function 'message-smtpmail-send-it)
- (setq smtpmail-smtp-server \"localhost\")
- (setq smtpmail-smtp-service \"25025\")
- (notmuch-hello)
- (notmuch-mua-mail)
- (message-goto-to)
- (insert \"u...@example.com\nDate: Fri, 29 Mar 1974 10:00:00 -\")
- (message-goto-subject)
- (insert \"Testing message sent via SMTP\")
- (message-goto-body)
- (insert \"This is a test that messages are sent via SMTP\")
- (message-send-and-exit)" >/dev/null 2>&1
-wait ${smtp_dummy_pid}
-
+emacs_deliver_message \
+'Testing message sent via SMTP' \
+'This is a test that messages are sent via SMTP' \
+'(message-goto-to)
+ (kill-whole-line)
+ (insert "To: u...@example.com\n")'
sed \
-e s',^User-Agent: Notmuch/.* Emacs/.*,User-Agent: Notmuch/XXX Emacs/XXX,'
\
-e s',^Message-ID: <.*>$,Message-ID: ,' < sent_message >OUTPUT
@@ -147,7 +131,7 @@ cat /dev/null
output=$(notmuch search 'subject:"testing message sent via SMTP"' |
notmuch_search_sanitize)
-test_expect_equal "$output" "thread:XXX 1974-03-29 [1/1] Notmuch Test Suite;
Testing message sent via SMTP (inbox)"
+test_expect_equal "$output" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite;
Testing message sent via SMTP (inbox)"
test_begin_subtest "notmuch-fcc-dirs set to nil"
test_emacs "(setq notmuch-fcc-dirs nil)
@@ -262,7 +246,7 @@ Subject: Re: Testing message sent via SMTP
In-Reply-To:
Fcc: $(pwd)/mail/sent
--text follows this line--
-On Fri, 29 Mar 1974 10:00:00 -, Notmuch Test Suite
wrote:
+On 01 Jan 2000 12:00:00 -, Notmuch Test Suite
wrote:
> This is a test that messages are sent via SMTP
EOF
test_expect_equal_file OUTPUT EXPECTED
--
1.7.5.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 05/10] test: save buffer content to file instead of printing it in Emacs tests
Before the change, the common Emacs test scheme was to print
buffer content to stdout and redirect it to a file or capture it
in a shell variable. This does not work if we switch to using
emacsclient(1) for running the tests, because you can not print
to the stdout in this case. (Actually, you can print to stdout
from Emacs server, but you can not capture the output on
emacsclient(1)).
The patch introduces new Emacs test auxiliary functions:
`test-output' and `test-visible-output'. These functions are
used to save buffer content to a file directly from Emacs. For
most tests the changes are trivial, because Emacs stdout output
was redirected to a file anyway. But some tests captured the
output in a shell variable and compare it with the expected
output using test_expect_equal. These tests are changed to use
files and test_expect_equal_file instead.
Note: even if we do not switch Emacs tests to emacsclient(1), the
patch makes tests cleaner and is an improvement.
---
test/emacs | 71 ---
test/emacs-large-search-buffer | 23 +
test/test-lib.el | 10 ++
3 files changed, 62 insertions(+), 42 deletions(-)
diff --git a/test/emacs b/test/emacs
index fddb4a1..8f8b841 100755
--- a/test/emacs
+++ b/test/emacs
@@ -8,7 +8,7 @@ add_email_corpus
test_begin_subtest "Basic notmuch-hello view in emacs"
test_emacs '(notmuch-hello)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
test_begin_subtest "Saved search with 0 results"
@@ -18,20 +18,20 @@ test_emacs '(setq notmuch-show-empty-saved-searches t)
("unread" . "tag:unread")
("empty" . "tag:doesnotexist")))
(notmuch-hello)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
test_begin_subtest "No saved searches displayed (all with 0 results)"
test_emacs '(setq notmuch-saved-searches
'\''(("empty" . "tag:doesnotexist")))
(notmuch-hello)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file 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)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-search-tag-inbox
test_begin_subtest "Navigation of notmuch-hello to search results"
@@ -40,27 +40,30 @@ test_emacs '(notmuch-hello)
(re-search-forward "inbox")
(widget-button-press (point))
(notmuch-test-wait)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file 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\")
- (princ (buffer-string))" >OUTPUT
+ (test-output)"
test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "notmuch-show for message with invalid From"
add_message "[subject]=\"message-with-invalid-from\"" \
"[from]=\"\\\"Invalid \\\" From\\\" \""
thread=$(notmuch search --output=threads subject:message-with-invalid-from)
-output=$(test_emacs "(notmuch-show \"$thread\") (princ (buffer-string))")
-test_expect_equal "$output" \
-'"Invalid " From" (2001-01-05) (inbox)
+test_emacs "(notmuch-show \"$thread\")
+ (test-output)"
+cat OUTPUT
+ (test-output)'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "Add tag from search view"
@@ -162,7 +165,7 @@ test_expect_equal "$output" "thread:XXX 1974-03-29 [1/1]
Notmuch Test Suite; T
test_begin_subtest "notmuch-fcc-dirs set to nil"
test_emacs "(setq notmuch-fcc-dirs nil)
(notmuch-mua-mail)
- (princ (buffer-string))" > OUTPUT
+ (test-output)"
cat
[PATCH 06/10] test: remove some sed(1) calls in Emacs tests
Few Emacs tests used sed(1) to remove unexpected output in the beginning to avoid getting confused by messages such as "Parsing /home/cworth/.mailrc... done". This is no longer needed since tests are run in a temporary home directory instead of the user's one. So remove these sed(1) calls. --- test/emacs |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/test/emacs b/test/emacs index 8f8b841..4592005 100755 --- a/test/emacs +++ b/test/emacs @@ -250,13 +250,10 @@ EOF test_expect_equal_file OUTPUT EXPECTED test_begin_subtest "Reply within emacs" -# We sed away everything before the ^From in the output to avoid getting -# confused by messages such as "Parsing /home/cworth/.mailrc... done" test_emacs '(notmuch-search "subject:\"testing message sent via SMTP\"") (notmuch-test-wait) (notmuch-search-reply-to-thread) (test-output)' -sed -i -ne '/^From/,$ p' OUTPUT sed -i -e 's/^In-Reply-To: <.*>$/In-Reply-To: /' OUTPUT cat
[PATCH 03/10] test: cleanup test_emacs
Move auxiliary function definition and configuration from command line to test-lib.el. --- test/test-lib.el |8 test/test-lib.sh |9 + 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/test/test-lib.el b/test/test-lib.el index 9439996..344a02e 100644 --- a/test/test-lib.el +++ b/test/test-lib.el @@ -20,6 +20,14 @@ ;; ;; Authors: Dmitry Kurochkin +;; avoid crazy 10-column default of --batch +(set-frame-width (window-frame (get-buffer-window)) 80) + +(defun notmuch-test-wait () + "Wait for process completion." + (while (get-buffer-process (current-buffer)) +(sleep-for 0.1))) + (defun visible-buffer-string () "Same as `buffer-string', but excludes invisible text." (visible-buffer-substring (point-min) (point-max))) diff --git a/test/test-lib.sh b/test/test-lib.sh index 3ec388c..5f61960 100755 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -852,18 +852,11 @@ fi # --directory Ensure that the local elisp sources are found # # --load Force loading of notmuch.el and test-lib.el -# -# notmuch-test-waitFunction for tests to use to wait for process completion -# -# set-frame-width 80 columns (avoids crazy 10-column default of --batch) emacs \$BATCH --no-init-file --no-site-file \ --directory ../../emacs --load notmuch.el \ --directory .. --load test-lib.el \ - --eval "(defun notmuch-test-wait () - (while (get-buffer-process (current-buffer)) - (sleep-for 0.1)))" \ - --eval "(progn (set-frame-width (window-frame (get-buffer-window)) 80) \$@)" + --eval "(progn \$@)" EOF chmod a+x ./run_emacs ./run_emacs "$@" -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 02/10] test: do not set `message-signature' in test_emacs
It is no longer needed since tests are run in a temporary home directory instead of the user's one. --- test/test-lib.sh |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/test/test-lib.sh b/test/test-lib.sh index cc20f41..3ec388c 100755 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -855,8 +855,6 @@ fi # # notmuch-test-waitFunction for tests to use to wait for process completion # -# message-signatureAvoiding appending user's signature on messages -# # set-frame-width 80 columns (avoids crazy 10-column default of --batch) emacs \$BATCH --no-init-file --no-site-file \ @@ -865,7 +863,6 @@ emacs \$BATCH --no-init-file --no-site-file \ --eval "(defun notmuch-test-wait () (while (get-buffer-process (current-buffer)) (sleep-for 0.1)))" \ - --eval "(setq message-signature nil)" \ --eval "(progn (set-frame-width (window-frame (get-buffer-window)) 80) \$@)" EOF chmod a+x ./run_emacs -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 01/10] test: fix argument order of test_expect_equal_file in few tests
Few Emacs tests had test_expect_equal_file arguments in the wrong order: the first argument should be the test output and the second one should be the expected. --- test/emacs |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/test/emacs b/test/emacs index 6f82b08..f4ff3f1 100755 --- a/test/emacs +++ b/test/emacs @@ -198,12 +198,12 @@ test_expect_equal_file OUTPUT EXPECTED test_begin_subtest "Save attachment from within emacs using notmuch-show-save-attachments" # save as archive to test that Emacs does not re-compress .gz echo ./attachment1.gz | test_emacs '(notmuch-show "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com") (notmuch-show-save-attachments)' > /dev/null 2>&1 -test_expect_equal_file "$EXPECTED/attachment" attachment1.gz +test_expect_equal_file attachment1.gz "$EXPECTED/attachment" test_begin_subtest "Save attachment from within emacs using notmuch-show-save-part" # save as archive to test that Emacs does not re-compress .gz echo ./attachment2.gz | test_emacs '(notmuch-show-save-part "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com" 5)' > /dev/null 2>&1 -test_expect_equal_file "$EXPECTED/attachment" attachment2.gz +test_expect_equal_file attachment2.gz "$EXPECTED/attachment" test_begin_subtest "View raw message within emacs" first_line=$(head -n1 $EXPECTED/raw-message-cf0c4d-52ad0a) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: use emacsclient(1) for Emacs tests
On Tue, 28 Jun 2011 00:17:42 -0400, Austin Clements wrote: > Quoth Dmitry Kurochkin on Jun 28 at 7:59 am: > > I am sure that would work, but I do not like the complexity. How about > > getting back to standard emacsclient and running a watchdog in the > > emacs? Like: > > > > (defun orphan-watchdog (pid) > > "Periodically check that the process with id PID is still > > running, quit if it terminated." > > (if (not (process-attributes pid)) > > (kill-emacs) > > (run-at-time "1 min" nil orphan-watchdog pid))) > > > > This function (or my other changes) do not work (by yet unknown reason > > :)), but you get the idea. > > I would consider this more complex than a few file descriptors. ]:--8) More shell code and more elisp code. I do not think can be considered simpler :) > Though, I'm automatically distrustful of anything that relies on > polling (why poll when you can be notified instantly?). > I agree that polling is not as elegant as an instant notification. But IMO reinventing emacsclient just kills all the beauty of this solution. I liked it when it was a simple read loop, but now it is too complex to my taste. Besides, I am a bit worried that we will face new problems in the future that would force us to add more "features" to our not-so-poor-man's Emacs server implementation. > It also has some problems. For example, PID's are easily reused, so > if another process happens to take up that PID, the emacs could still > hang around for a long time. Indeed. We may add a more complex process detection, but IMO it is an overkill. Anyway, I am done with reworking the patch series and will post it now. Perhaps others would voice their opinion on this one. Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Notmuch scripts
On Fri, 24 Jun 2011 11:29:21 -0700, Carl Worth wrote: > > * Spam filter. Do you guys use any? What does it's interface look like? > > I currently use bsfilter which I've found does it's job pretty > > well. > > I've currently got amavis and spamassassin adding extra headers, (and > below a certain threshold I've got maildrop delivering detected spam to > a separate maildir). > > Currently, notmuch never sees the detected spam. Ever since we got > folder: support I've been meaning to let notmuch see it so that I can > use notmuch to dig into my spam when I suspect something got > mis-detected. > > I don't currently have any system for getting user-provided feedback > into my spam filtering. Do you get that with bsfilter? > I use bogofilter along with a python cron job to bring my tags and the spam filter into sync. I use a tag (junk) to mark mail as spam and two other tags (.bf_ham and .bf_spam) to indicate that the message has been added to bogofilter. The script's task is then to, * Unregister as spam, register as ham messages with tag:.bf_spam and not tag:junk with bogofilter * Register as spam, unregister as ham messages with tag:junk and not tag:.bf_spam This is pretty straightforward to implement and is quite effective. It would be nice, however, if the emacs interface supported hiding tags matching certain patterns (say /\..+/). - Ben
Re: [PATCH 2/2] test: use emacsclient(1) for Emacs tests
Quoth Dmitry Kurochkin on Jun 28 at 7:59 am: > I am sure that would work, but I do not like the complexity. How about > getting back to standard emacsclient and running a watchdog in the > emacs? Like: > > (defun orphan-watchdog (pid) > "Periodically check that the process with id PID is still > running, quit if it terminated." > (if (not (process-attributes pid)) > (kill-emacs) > (run-at-time "1 min" nil orphan-watchdog pid))) > > This function (or my other changes) do not work (by yet unknown reason > :)), but you get the idea. I would consider this more complex than a few file descriptors. ]:--8) Though, I'm automatically distrustful of anything that relies on polling (why poll when you can be notified instantly?). It also has some problems. For example, PID's are easily reused, so if another process happens to take up that PID, the emacs could still hang around for a long time. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: use emacsclient(1) for Emacs tests
On Mon, 27 Jun 2011 23:49:37 -0400, Austin Clements wrote:
> Quoth Dmitry Kurochkin on Jun 28 at 5:03 am:
> > > > The only way I know to
> > > > reliably kill a child process is to open a pipe to it and have it exit
> > > > on its own when it reads EOF. Unfortunately, I couldn't find a way to
> > > > do this with an emacs daemon (it appears daemon mode aggressively
> > > > cleans up things like pipes), but here's a different approach:
> > > >
> > > > coproc emacs --batch --eval "(while t (eval (read)))"
> > > > EMACSFD=${COPROC[1]}
> > > > trap "echo '(kill-emacs)' >&$EMACSFD" EXIT
> > > >
> > > > echo '(message "Hi")' >&$EMACSFD
> > > > # ...
> > > >
> > > > This is, basically, a poor man's emacs server, but the coprocess pipe
> > > > binds it tightly to the shell. If the shell exits for *any* reason,
> > > > the pipe will be closed by the kernel, emacs will read an EOF, and
> > > > exit.
> > >
> > > I like this idea.
> > >
> > > > The trap is there just to cleanly shut down in case of a normal
> > > > exit [1].
> > >
> > > For normal exit we should just put this into test_done. Otherwise it is
> > > not a normal exit and we do not care about Emacs error message. No?
> > >
> > > > This also has the advantage that read-from-minibuffer still
> > > > works:
> > > >
> > > > echo '(message (read-from-minibuffer ""))' >&$EMACSFD
> > > > echo 'Test' >&$EMACSFD
> > > >
> > > > Thoughts?
> > > >
> > >
> > > I like it and I will implement it. Thanks for the idea.
> > >
> >
> > While implementing the idea, I stumbled upon a problem: we need to know
> > when Emacs finished what we echoed or failed with an error. At the
> > moment tests fail because they check for OUTPUT before Emacs creates it.
> >
> > We can tell Emacs to print some special marker and wait for it. But
> > there may be exceptions and errors which may make it difficult. I did
> > not found a good solution yet. Would love to hear your thoughts :)
>
> Oof, yes, of course. How about making the one-line poor man's emacs
> server slightly less poor? Use a FIFO to communicate completion.
> Something like,
>
> EMACSDONE=$TEST_DIRECTORY/emacsdone
> mkfifo $EMACSDONE
> coproc emacs --batch --eval '(while t (eval (read)) (write-region "\n" nil
> "'$EMACSDONE'" t 0))'
> EMACSFD=${COPROC[1]}
>
> test_emacs() {
> echo "$1" >&$EMACSFD
> read <$EMACSDONE
> }
>
> test_emacs '(sleep-for 2)'
> test_emacs '(message "Hi")'
>
> echo '(kill-emacs)' >&$EMACSFD
I am sure that would work, but I do not like the complexity. How about
getting back to standard emacsclient and running a watchdog in the
emacs? Like:
(defun orphan-watchdog (pid)
"Periodically check that the process with id PID is still
running, quit if it terminated."
(if (not (process-attributes pid))
(kill-emacs)
(run-at-time "1 min" nil orphan-watchdog pid)))
This function (or my other changes) do not work (by yet unknown reason
:)), but you get the idea.
Regards,
Dmitry
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: use emacsclient(1) for Emacs tests
Quoth Dmitry Kurochkin on Jun 28 at 5:03 am:
> > > The only way I know to
> > > reliably kill a child process is to open a pipe to it and have it exit
> > > on its own when it reads EOF. Unfortunately, I couldn't find a way to
> > > do this with an emacs daemon (it appears daemon mode aggressively
> > > cleans up things like pipes), but here's a different approach:
> > >
> > > coproc emacs --batch --eval "(while t (eval (read)))"
> > > EMACSFD=${COPROC[1]}
> > > trap "echo '(kill-emacs)' >&$EMACSFD" EXIT
> > >
> > > echo '(message "Hi")' >&$EMACSFD
> > > # ...
> > >
> > > This is, basically, a poor man's emacs server, but the coprocess pipe
> > > binds it tightly to the shell. If the shell exits for *any* reason,
> > > the pipe will be closed by the kernel, emacs will read an EOF, and
> > > exit.
> >
> > I like this idea.
> >
> > > The trap is there just to cleanly shut down in case of a normal
> > > exit [1].
> >
> > For normal exit we should just put this into test_done. Otherwise it is
> > not a normal exit and we do not care about Emacs error message. No?
> >
> > > This also has the advantage that read-from-minibuffer still
> > > works:
> > >
> > > echo '(message (read-from-minibuffer ""))' >&$EMACSFD
> > > echo 'Test' >&$EMACSFD
> > >
> > > Thoughts?
> > >
> >
> > I like it and I will implement it. Thanks for the idea.
> >
>
> While implementing the idea, I stumbled upon a problem: we need to know
> when Emacs finished what we echoed or failed with an error. At the
> moment tests fail because they check for OUTPUT before Emacs creates it.
>
> We can tell Emacs to print some special marker and wait for it. But
> there may be exceptions and errors which may make it difficult. I did
> not found a good solution yet. Would love to hear your thoughts :)
Oof, yes, of course. How about making the one-line poor man's emacs
server slightly less poor? Use a FIFO to communicate completion.
Something like,
EMACSDONE=$TEST_DIRECTORY/emacsdone
mkfifo $EMACSDONE
coproc emacs --batch --eval '(while t (eval (read)) (write-region "\n" nil
"'$EMACSDONE'" t 0))'
EMACSFD=${COPROC[1]}
test_emacs() {
echo "$1" >&$EMACSFD
read <$EMACSDONE
}
test_emacs '(sleep-for 2)'
test_emacs '(message "Hi")'
echo '(kill-emacs)' >&$EMACSFD
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: interaction between --format=raw and multipart handling [was: Re: Do not attept to output part raw if part is not GMimePart.]
On Mon, Jun 27, 2011 at 6:41 PM, Daniel Kahn Gillmor wrote: > On 06/27/2011 06:07 PM, Austin Clements wrote: >> Oh, right, of course. show_message_part will walk into the parts, so >> format_part_content_raw will still be called on the leafs of a >> requested multipart. Though, this approach results in each leaf being >> transfer decoded and printed individually, so if you ask for a >> multipart, you won't get the "raw" contents of the multipart (unless >> it's part 0), so much as you get the concatenated "raw" contents of >> each part in the multipart. > > > let's take two labeled examples: > > A└┬╴multipart/signed 58292 bytes > B ├┬╴multipart/mixed 56553 bytes > C │├╴text/plain 1278 bytes > D │├╴text/plain attachment [grub-install.out] 54109 bytes > E │└╴text/x-diff attachment [597538.patch] 496 bytes > F └╴application/pgp-signature attachment [signature.asc] 900 bytes > > > X└┬╴multipart/signed 3863 bytes > Y ├╴text/plain 1857 bytes > Z └╴application/pgp-signature attachment [signature.asc] 900 bytes > > (i know, you won't use "A" or "Z" as part IDs once we have hierarchical > part numbers, but consider them placeholders). > > if parts F or Z are ever going to be useful (e.g. to some external > process that wants to validate the signature by hand), then the tool > needs to provide some way of producing parts B and Y in a pristine form > (that is, including MIME headers and without interpreting/applying any > transfer encodings). > > Perhaps this means there are two flavors of "raw" that we should be > distinguishing, something like: > > 0) "source" -- the equivalent to viewing the source of the message, > with headers and without attempting to reverse transfer-encodings, etc. > > 1) "rare" -- (not entirely raw, but still bloody, ha ha) strip headers, > reverse transfer encodings, etc. > > I think our current implementation of --format=raw emits "source" when > applied to the entire message, but "rare" when applied to one of the parts. Yes. > I'm suggesting that it might be useful to be able to get "source" of a > part. (and perhaps it might also be useful to get the whole message > "rare" sometimes?) > > My first instinct was: if it's multipart, provide "source", if it's > single-part, provide "rare". But that fails for the XYZ case above -- > we'd need Y (which is single-part) to be provided as "source" if we were > ever to be able to make use of Z on its own, so i don't think it'll be > that simple. > > OTOH, i'm not sure that "rare" is particularly meaningful for non-leaf > parts. > >> That if you ask for a multipart, you should effectively get a slice >> out of the original message bytes (since multipart/* parts can't have >> non-identity transfer encodings). Are you also saying that should >> extend to transfer encoded leaf parts, too? > > hmm. is it true that multipart/* parts can't have non-identity transfer > encodings? that would simplify some things, but i don't have a > reference handy that says it's the case. RFC 2045, section 6.4: "If an entity is of type "multipart" the Content-Transfer-Encoding is not permitted to have any value other than "7bit", "8bit" or "binary"." (And, for completeness, section 6.2: "The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all mean that the identity (i.e. NO) encoding transformation has been performed.") > At any rate, i'm not sure it affects the need for being able to emit > both "rare" and "source" forms of at least the leaf (non-multipart) parts. > > i hope this is all at least somewhat clarifying and not just adding to > the confusion, Thanks. That's actually very informative and solidifies some of what's been slowly coagulating in my mind. I was also thinking about the two output variants you describe (though, being less clever, I was thinking "raw" and "decoded"). The fact that multipart/* parts can only have identity encodings makes me wonder if the two could be merged by thinking of the decoded content of a leaf part as a child/body to the original, encoded part. On the other hand, that doesn't make sense for other formats, so perhaps that's not a fruitful approach. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
interaction between --format=raw and multipart handling [was: Re: Do not attept to output part raw if part is not GMimePart.]
On 06/27/2011 06:07 PM, Austin Clements wrote: > Oh, right, of course. show_message_part will walk into the parts, so > format_part_content_raw will still be called on the leafs of a > requested multipart. Though, this approach results in each leaf being > transfer decoded and printed individually, so if you ask for a > multipart, you won't get the "raw" contents of the multipart (unless > it's part 0), so much as you get the concatenated "raw" contents of > each part in the multipart. let's take two labeled examples: A???multipart/signed 58292 bytes B ???multipart/mixed 56553 bytes C ???text/plain 1278 bytes D ???text/plain attachment [grub-install.out] 54109 bytes E ???text/x-diff attachment [597538.patch] 496 bytes F ??application/pgp-signature attachment [signature.asc] 900 bytes X???multipart/signed 3863 bytes Y ??text/plain 1857 bytes Z ??application/pgp-signature attachment [signature.asc] 900 bytes (i know, you won't use "A" or "Z" as part IDs once we have hierarchical part numbers, but consider them placeholders). if parts F or Z are ever going to be useful (e.g. to some external process that wants to validate the signature by hand), then the tool needs to provide some way of producing parts B and Y in a pristine form (that is, including MIME headers and without interpreting/applying any transfer encodings). Perhaps this means there are two flavors of "raw" that we should be distinguishing, something like: 0) "source" -- the equivalent to viewing the source of the message, with headers and without attempting to reverse transfer-encodings, etc. 1) "rare" -- (not entirely raw, but still bloody, ha ha) strip headers, reverse transfer encodings, etc. I think our current implementation of --format=raw emits "source" when applied to the entire message, but "rare" when applied to one of the parts. I'm suggesting that it might be useful to be able to get "source" of a part. (and perhaps it might also be useful to get the whole message "rare" sometimes?) My first instinct was: if it's multipart, provide "source", if it's single-part, provide "rare". But that fails for the XYZ case above -- we'd need Y (which is single-part) to be provided as "source" if we were ever to be able to make use of Z on its own, so i don't think it'll be that simple. OTOH, i'm not sure that "rare" is particularly meaningful for non-leaf parts. > Daniel, is this the problem that you're getting at with "opacity"? the origin of the term "opaque" used in this context can be found in the definition of multipart/signed: https://tools.ietf.org/html/rfc1847#section-2.1 > That if you ask for a multipart, you should effectively get a slice > out of the original message bytes (since multipart/* parts can't have > non-identity transfer encodings). Are you also saying that should > extend to transfer encoded leaf parts, too? hmm. is it true that multipart/* parts can't have non-identity transfer encodings? that would simplify some things, but i don't have a reference handy that says it's the case. At any rate, i'm not sure it affects the need for being able to emit both "rare" and "source" forms of at least the leaf (non-multipart) parts. i hope this is all at least somewhat clarifying and not just adding to the confusion, --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110627/e2242ea7/attachment.pgp>
Re: Notmuch scripts
On Fri, 24 Jun 2011 11:29:21 -0700, Carl Worth wrote: > > * Spam filter. Do you guys use any? What does it's interface look like? > > I currently use bsfilter which I've found does it's job pretty > > well. > > I've currently got amavis and spamassassin adding extra headers, (and > below a certain threshold I've got maildrop delivering detected spam to > a separate maildir). > > Currently, notmuch never sees the detected spam. Ever since we got > folder: support I've been meaning to let notmuch see it so that I can > use notmuch to dig into my spam when I suspect something got > mis-detected. > > I don't currently have any system for getting user-provided feedback > into my spam filtering. Do you get that with bsfilter? > I use bogofilter along with a python cron job to bring my tags and the spam filter into sync. I use a tag (junk) to mark mail as spam and two other tags (.bf_ham and .bf_spam) to indicate that the message has been added to bogofilter. The script's task is then to, * Unregister as spam, register as ham messages with tag:.bf_spam and not tag:junk with bogofilter * Register as spam, unregister as ham messages with tag:junk and not tag:.bf_spam This is pretty straightforward to implement and is quite effective. It would be nice, however, if the emacs interface supported hiding tags matching certain patterns (say /\..+/). - Ben ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Do not attept to output part raw if part is not GMimePart.
Quoth Jameson Graef Rollins on Jun 27 at 2:44 pm: > On Mon, 27 Jun 2011 16:43:36 -0400, Austin Clements > wrote: > > Just to clarify my understanding, --format=raw is only intended to > > work on either the whole message (special-cased in do_show_single) or > > a leaf MIME part, and in any other case, it will output nothing? The > > raw output test cases seem pretty thin. > > Hey, Austin. The raw part output works for *any* part, be it leaf part, > multipart, message/rfc822, etc. I added a bunch of tests for raw part > output that should cover all of this, although I don't think they've > been pulled into master yet. Oh, right, of course. show_message_part will walk into the parts, so format_part_content_raw will still be called on the leafs of a requested multipart. Though, this approach results in each leaf being transfer decoded and printed individually, so if you ask for a multipart, you won't get the "raw" contents of the multipart (unless it's part 0), so much as you get the concatenated "raw" contents of each part in the multipart. Daniel, is this the problem that you're getting at with "opacity"? That if you ask for a multipart, you should effectively get a slice out of the original message bytes (since multipart/* parts can't have non-identity transfer encodings). Are you also saying that should extend to transfer encoded leaf parts, too? > I think there are a lot of open questions about what should be output > for multipart raw. We should output _something_, though. I think we > can fix all of this up for 0.7, based on the work you've already done, > after 0.6 is released. Yes, hopefully. That's why I'm making sure I understand the issues here. ]:--8)
Re: [PATCH 2/2] test: use emacsclient(1) for Emacs tests
Austin,
On Tue, 28 Jun 2011 00:22:41 +0400, Dmitry Kurochkin
wrote:
> On Mon, 27 Jun 2011 16:02:12 -0400, Austin Clements wrote:
> > This looks like a great idea! The test suite has been getting irritating
> > slow.
> >
> > A few minor comments: This patch would be clearer if it the
> > setq-to-let translation were a separate patch. It would also be worth
> > adding a big comment at the top of the test explaining why all of the
> > tests let-bind everything instead of setq'ing, primarily for the
> > benefit of people writing new tests.
> >
>
> Agreed, will separate and add the warning.
>
> > I might just be having trouble reading the patch, but the difference
> > between emacs_start and emacs_server_start seems unclear. Perhaps the
> > comments should explain how somebody would use these scripts?
> >
>
> emacs_start start a normal Emacs in non-daemon mode. Something you
> might prefer when debugging.
>
> >
> > My bigger concern with this change is that it may leave behind stale
> > emacs daemons if the script gets interrupted.
>
> That is an issue indeed. I would probably do smth like a periodic check
> inside Emacs that the shell is alive, but your approach below looks more
> reliable.
>
> > The only way I know to
> > reliably kill a child process is to open a pipe to it and have it exit
> > on its own when it reads EOF. Unfortunately, I couldn't find a way to
> > do this with an emacs daemon (it appears daemon mode aggressively
> > cleans up things like pipes), but here's a different approach:
> >
> > coproc emacs --batch --eval "(while t (eval (read)))"
> > EMACSFD=${COPROC[1]}
> > trap "echo '(kill-emacs)' >&$EMACSFD" EXIT
> >
> > echo '(message "Hi")' >&$EMACSFD
> > # ...
> >
> > This is, basically, a poor man's emacs server, but the coprocess pipe
> > binds it tightly to the shell. If the shell exits for *any* reason,
> > the pipe will be closed by the kernel, emacs will read an EOF, and
> > exit.
>
> I like this idea.
>
> > The trap is there just to cleanly shut down in case of a normal
> > exit [1].
>
> For normal exit we should just put this into test_done. Otherwise it is
> not a normal exit and we do not care about Emacs error message. No?
>
> > This also has the advantage that read-from-minibuffer still
> > works:
> >
> > echo '(message (read-from-minibuffer ""))' >&$EMACSFD
> > echo 'Test' >&$EMACSFD
> >
> > Thoughts?
> >
>
> I like it and I will implement it. Thanks for the idea.
>
While implementing the idea, I stumbled upon a problem: we need to know
when Emacs finished what we echoed or failed with an error. At the
moment tests fail because they check for OUTPUT before Emacs creates it.
We can tell Emacs to print some special marker and wait for it. But
there may be exceptions and errors which may make it difficult. I did
not found a good solution yet. Would love to hear your thoughts :)
Regards,
Dmitry
> Regards,
> Dmitry
>
> > [1] If you don't do this, emacs complains that it can't read from
> > stdin before it exits. It would be nice to catch this condition in
> > the elisp code and not bother with the trap, but the error thrown is
> > just an 'error, so I don't think we can catch and ignore it without
> > catching and ignoring *all* errors.
> >
> > On Sun, Jun 26, 2011 at 11:54 PM, Dmitry Kurochkin
> > wrote:
> > > Before the change, every Emacs tests ran in a separate Emacs
> > > instance. Starting Emacs many times wastes considerable time and
> > > it gets worse as the test suite grows. The patch solves this by
> > > using a single Emacs server and emacsclient(1) to run multiple
> > > tests. Emacs server is started on the first test_emacs call and
> > > stopped when test_done is called or the test is killed by a
> > > signal. Several auxiliary scripts useful for debugging and test
> > > development are generated instead of the run_emacs script:
> > >
> > > * emacs_server_start - start Emacs server
> > > * emacs_server_stop - stop Emacs server
> > > * emacs_start - start Emacs
> > > * emacs_run - execute ELisp expressions in running Emacs server
> > >
> > > Since multiple tests are run in a single Emacs instance, they
> > > must not change Emacs environment because it may affect other
> > > tests. For now, the only Emacs environment modifications done by
> > > the tests are variable settings. Before the change, variables
> > > were set with `setq' which affected other tests. The patch
> > > changes all variables to use `let', so the scope of the change is
> > > limited to a single test.
> > > ---
> > > test/emacs | 74 +-
> > > test/test-lib.el | 6 ++
> > > test/test-lib.sh | 149
> > > ++---
> > > 3 files changed, 161 insertions(+), 68 deletions(-)
> > >
> > > diff --git a/test/emacs b/test/emacs
> > > index 4f16b41..f1939dc 100755
> > > --- a/test/emacs
> > > +++ b/test/emacs
> > > @@ -1
[PATCH] Do not attept to output part raw if part is not GMimePart.
On 06/27/2011 04:43 PM, Austin Clements wrote: > Just to clarify my understanding, --format=raw is only intended to > work on either the whole message (special-cased in do_show_single) or > a leaf MIME part, and in any other case, it will output nothing? The > raw output test cases seem pretty thin. I personally think that --format=raw *should* work on non-leaf parts; i don't know if that was the original intent. > (BTW, I believe the show restructuring I have under way should both > lift this restriction and eliminate the special case.) I hope the tests for this feature can eventually include some weird compound parts with whitespace-wrapped header lines, odd MIME delimiters, character encodings, etc. It would be really good if the --part=whatever --format=raw output produces byte-for-byte identical streams. Both PGP/MIME and S/MIME signatures rely on explicit opacity of the signed MIME parts, so being able to retrieve the signed data precisely would be quite useful for weird corner cases. --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110627/88d7b382/attachment.pgp>
[PATCH] test:Improve test behaviors when --root is used
On Mon, 27 Jun 2011 15:50:47 -0500, Austin Clements wrote:
> This looks great (modulo one bug, below). I've wanted to run the
> tests on tmpfs before, but was too lazy to actually fix the tests.
>
> Given how easy it is to accidentally use "..", I wonder if there's a
> way to force people to use $TEST_DIRECTORY?
I was thinking of a test of the test-suite running in this mode, but I
didn't quite feel comfortable, since it feels a bit slow sometimes
already.
So an instruction to run 'make test', which would include a 'make test
OPTIONS="--root=/dev/shm/notmuch_test.$$"' or some such if that was
acceptable.
I didn't think about it very hard, but I was intrigued by the idea.
-Mark
> On Mon, Jun 27, 2011 at 12:09 PM, Mark Anderson wrote:
> > --- a/test/symbol-hiding
> > +++ b/test/symbol-hiding
> > @@ -12,13 +12,13 @@ test_description='exception symbol hiding'
> > ?. ./test-lib.sh
> >
> > ?run_test(){
> > - ? ?result=$(LD_LIBRARY_PATH=../../lib ./symbol-test 2>&1)
> > + ? ?result=$(LD_LIBRARY_PATH=$TEST_DIRECTORY/../../lib ./symbol-test 2>&1)
>
> Did you mean $TEST_DIRECTORY/../lib?
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
[PATCH] test:Folder tags shouldn't match after removal of file in given folder
On Mon, Jun 27, 2011 at 1:12 PM, Mark Anderson wrote: > +test_begin_subtest "Test matches folder:spam" > +output=$(notmuch search folder:spam) > +test_expect_equal "$output" "thread:0001 ? 2001-01-05 [1/1] > Notmuch Test Suite; Test message #1 (inbox unread)" > + > +sleep 1; I assume this has to do with directory mtime's. Is it sufficient to instead increment_mtime $dir/spam after the rm below? > + > +test_begin_subtest "Remove folder:spam copy of email" > +rm $dir/spam/$(basename $file_x) > +output=$(NOTMUCH_NEW) > +test_expect_equal "$output" "No new mail. Detected 1 file rename."
[PATCH] test:Folder tags shouldn't match after removal of file in given folder
On Mon, 27 Jun 2011 15:58:00 -0500, Austin Clements wrote: > On Mon, Jun 27, 2011 at 1:12 PM, Mark Anderson wrote: > > +test_begin_subtest "Test matches folder:spam" > > +output=$(notmuch search folder:spam) > > +test_expect_equal "$output" "thread:0001 ? 2001-01-05 [1/1] > > Notmuch Test Suite; Test message #1 (inbox unread)" > > + > > +sleep 1; > > I assume this has to do with directory mtime's. Is it sufficient to > instead increment_mtime $dir/spam after the rm below? I believe that would be sufficient. I just had one of my runs fail to even remove the filename, and I remember some earlier discussion along these lines, but I just used the fastest way, I can certainly modify it to use "increment_mtime" > > > + > > +test_begin_subtest "Remove folder:spam copy of email" > > +rm $dir/spam/$(basename $file_x) > > +output=$(NOTMUCH_NEW) > > +test_expect_equal "$output" "No new mail. Detected 1 file rename." > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch >
[PATCH] test:Improve test behaviors when --root is used
This looks great (modulo one bug, below). I've wanted to run the
tests on tmpfs before, but was too lazy to actually fix the tests.
Given how easy it is to accidentally use "..", I wonder if there's a
way to force people to use $TEST_DIRECTORY?
On Mon, Jun 27, 2011 at 12:09 PM, Mark Anderson wrote:
> --- a/test/symbol-hiding
> +++ b/test/symbol-hiding
> @@ -12,13 +12,13 @@ test_description='exception symbol hiding'
> ?. ./test-lib.sh
>
> ?run_test(){
> - ? ?result=$(LD_LIBRARY_PATH=../../lib ./symbol-test 2>&1)
> + ? ?result=$(LD_LIBRARY_PATH=$TEST_DIRECTORY/../../lib ./symbol-test 2>&1)
Did you mean $TEST_DIRECTORY/../lib?
[PATCH] Do not attept to output part raw if part is not GMimePart.
On Mon, Jun 27, 2011 at 1:07 PM, Jameson Graef Rollins wrote: > On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth wrote: >> I'd like to investigate this case a little bit to help answer the >> question of whether "notmuch should have done anything in this case". > > Hi, Carl. ?You can see this error if you try to output raw a multipart/* > or message/rfc822 part, ie: > > servo:~ 0$ notmuch show --part=1 --format=raw id:"87wrgccedd.fsf at > yoom.home.cworth.org" >/dev/null > > (process:29838): GLib-GObject-WARNING **: invalid cast from > `GMimeMultipartSigned' to `GMimePart' > > (process:29838): gmime-CRITICAL **: g_mime_part_get_content_object: assertion > `GMIME_IS_PART (mime_part)' failed > servo:~ 0$ > > Gmime seems to be successfully casting the part into GMimePart and then > outputting the content, but it does produce the warning on stderr. Just to clarify my understanding, --format=raw is only intended to work on either the whole message (special-cased in do_show_single) or a leaf MIME part, and in any other case, it will output nothing? The raw output test cases seem pretty thin. (BTW, I believe the show restructuring I have under way should both lift this restriction and eliminate the special case.)
[PATCH 2/2] test: use emacsclient(1) for Emacs tests
On Mon, Jun 27, 2011 at 4:22 PM, Dmitry Kurochkin wrote: > On Mon, 27 Jun 2011 16:02:12 -0400, Austin Clements > wrote: >> ?The trap is there just to cleanly shut down in case of a normal >> exit [1]. > > For normal exit we should just put this into test_done. ?Otherwise it is > not a normal exit and we do not care about Emacs error message. ?No? Yes, that's good, too, and it avoids the standard pitfalls of trap.
Re: [PATCH] test:Improve test behaviors when --root is used
On Mon, 27 Jun 2011 15:50:47 -0500, Austin Clements wrote:
> This looks great (modulo one bug, below). I've wanted to run the
> tests on tmpfs before, but was too lazy to actually fix the tests.
>
> Given how easy it is to accidentally use "..", I wonder if there's a
> way to force people to use $TEST_DIRECTORY?
I was thinking of a test of the test-suite running in this mode, but I
didn't quite feel comfortable, since it feels a bit slow sometimes
already.
So an instruction to run 'make test', which would include a 'make test
OPTIONS="--root=/dev/shm/notmuch_test.$$"' or some such if that was
acceptable.
I didn't think about it very hard, but I was intrigued by the idea.
-Mark
> On Mon, Jun 27, 2011 at 12:09 PM, Mark Anderson wrote:
> > --- a/test/symbol-hiding
> > +++ b/test/symbol-hiding
> > @@ -12,13 +12,13 @@ test_description='exception symbol hiding'
> > . ./test-lib.sh
> >
> > run_test(){
> > - result=$(LD_LIBRARY_PATH=../../lib ./symbol-test 2>&1)
> > + result=$(LD_LIBRARY_PATH=$TEST_DIRECTORY/../../lib ./symbol-test 2>&1)
>
> Did you mean $TEST_DIRECTORY/../lib?
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] test: use emacsclient(1) for Emacs tests
This looks like a great idea! The test suite has been getting irritating slow.
A few minor comments: This patch would be clearer if it the
setq-to-let translation were a separate patch. It would also be worth
adding a big comment at the top of the test explaining why all of the
tests let-bind everything instead of setq'ing, primarily for the
benefit of people writing new tests.
I might just be having trouble reading the patch, but the difference
between emacs_start and emacs_server_start seems unclear. Perhaps the
comments should explain how somebody would use these scripts?
My bigger concern with this change is that it may leave behind stale
emacs daemons if the script gets interrupted. The only way I know to
reliably kill a child process is to open a pipe to it and have it exit
on its own when it reads EOF. Unfortunately, I couldn't find a way to
do this with an emacs daemon (it appears daemon mode aggressively
cleans up things like pipes), but here's a different approach:
coproc emacs --batch --eval "(while t (eval (read)))"
EMACSFD=${COPROC[1]}
trap "echo '(kill-emacs)' >&$EMACSFD" EXIT
echo '(message "Hi")' >&$EMACSFD
# ...
This is, basically, a poor man's emacs server, but the coprocess pipe
binds it tightly to the shell. If the shell exits for *any* reason,
the pipe will be closed by the kernel, emacs will read an EOF, and
exit. The trap is there just to cleanly shut down in case of a normal
exit [1]. This also has the advantage that read-from-minibuffer still
works:
echo '(message (read-from-minibuffer ""))' >&$EMACSFD
echo 'Test' >&$EMACSFD
Thoughts?
[1] If you don't do this, emacs complains that it can't read from
stdin before it exits. It would be nice to catch this condition in
the elisp code and not bother with the trap, but the error thrown is
just an 'error, so I don't think we can catch and ignore it without
catching and ignoring *all* errors.
On Sun, Jun 26, 2011 at 11:54 PM, Dmitry Kurochkin
wrote:
> Before the change, every Emacs tests ran in a separate Emacs
> instance. ?Starting Emacs many times wastes considerable time and
> it gets worse as the test suite grows. ?The patch solves this by
> using a single Emacs server and emacsclient(1) to run multiple
> tests. ?Emacs server is started on the first test_emacs call and
> stopped when test_done is called or the test is killed by a
> signal. ?Several auxiliary scripts useful for debugging and test
> development are generated instead of the run_emacs script:
>
> ?* emacs_server_start - start Emacs server
> ?* emacs_server_stop ?- stop Emacs server
> ?* emacs_start ? ? ? ?- start Emacs
> ?* emacs_run ? ? ? ? ?- execute ELisp expressions in running Emacs server
>
> Since multiple tests are run in a single Emacs instance, they
> must not change Emacs environment because it may affect other
> tests. ?For now, the only Emacs environment modifications done by
> the tests are variable settings. ?Before the change, variables
> were set with `setq' which affected other tests. ?The patch
> changes all variables to use `let', so the scope of the change is
> limited to a single test.
> ---
> ?test/emacs ? ? ? | ? 74 +-
> ?test/test-lib.el | ? ?6 ++
> ?test/test-lib.sh | ?149 ++---
> ?3 files changed, 161 insertions(+), 68 deletions(-)
>
> diff --git a/test/emacs b/test/emacs
> index 4f16b41..f1939dc 100755
> --- a/test/emacs
> +++ b/test/emacs
> @@ -12,20 +12,20 @@ test_emacs '(notmuch-hello)
> ?test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
>
> ?test_begin_subtest "Saved search with 0 results"
> -test_emacs '(setq notmuch-show-empty-saved-searches t)
> - ? ? ? ? ? (setq notmuch-saved-searches
> - ? ? ? ? ? ? ? ? '\''(("inbox" . "tag:inbox")
> - ? ? ? ? ? ? ? ? ? ? ?("unread" . "tag:unread")
> - ? ? ? ? ? ? ? ? ? ? ?("empty" . "tag:doesnotexist")))
> - ? ? ? ? ? (notmuch-hello)
> - ? ? ? ? ? (test-output)'
> +test_emacs '(let ((notmuch-show-empty-saved-searches t)
> + ? ? ? ? ? ? ? ? (notmuch-saved-searches
> + ? ? ? ? ? ? ? ? ?'\''(("inbox" . "tag:inbox")
> + ? ? ? ? ? ? ? ? ? ? ? ("unread" . "tag:unread")
> + ? ? ? ? ? ? ? ? ? ? ? ("empty" . "tag:doesnotexist"
> + ? ? ? ? ? ? (notmuch-hello)
> + ? ? ? ? ? ? (test-output))'
> ?test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
>
> ?test_begin_subtest "No saved searches displayed (all with 0 results)"
> -test_emacs '(setq notmuch-saved-searches
> - ? ? ? ? ? ? ? ? '\''(("empty" . "tag:doesnotexist")))
> - ? ? ? ? ? (notmuch-hello)
> - ? ? ? ? ? (test-output)'
> +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_begin_subtest "Basic notmuch-search view in emacs"
> @@ -147,9 +147,9 @@ output=$(notmuch search 'subject:"testing message sent
> via SMTP"' | notmuch
Re: [PATCH] test:Folder tags shouldn't match after removal of file in given folder
On Mon, 27 Jun 2011 15:58:00 -0500, Austin Clements wrote: > On Mon, Jun 27, 2011 at 1:12 PM, Mark Anderson wrote: > > +test_begin_subtest "Test matches folder:spam" > > +output=$(notmuch search folder:spam) > > +test_expect_equal "$output" "thread:0001 2001-01-05 [1/1] > > Notmuch Test Suite; Test message #1 (inbox unread)" > > + > > +sleep 1; > > I assume this has to do with directory mtime's. Is it sufficient to > instead increment_mtime $dir/spam after the rm below? I believe that would be sufficient. I just had one of my runs fail to even remove the filename, and I remember some earlier discussion along these lines, but I just used the fastest way, I can certainly modify it to use "increment_mtime" > > > + > > +test_begin_subtest "Remove folder:spam copy of email" > > +rm $dir/spam/$(basename $file_x) > > +output=$(NOTMUCH_NEW) > > +test_expect_equal "$output" "No new mail. Detected 1 file rename." > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch > ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
interaction between --format=raw and multipart handling [was: Re: Do not attept to output part raw if part is not GMimePart.]
On 06/27/2011 06:07 PM, Austin Clements wrote: > Oh, right, of course. show_message_part will walk into the parts, so > format_part_content_raw will still be called on the leafs of a > requested multipart. Though, this approach results in each leaf being > transfer decoded and printed individually, so if you ask for a > multipart, you won't get the "raw" contents of the multipart (unless > it's part 0), so much as you get the concatenated "raw" contents of > each part in the multipart. let's take two labeled examples: A└┬╴multipart/signed 58292 bytes B ├┬╴multipart/mixed 56553 bytes C │├╴text/plain 1278 bytes D │├╴text/plain attachment [grub-install.out] 54109 bytes E │└╴text/x-diff attachment [597538.patch] 496 bytes F └╴application/pgp-signature attachment [signature.asc] 900 bytes X└┬╴multipart/signed 3863 bytes Y ├╴text/plain 1857 bytes Z └╴application/pgp-signature attachment [signature.asc] 900 bytes (i know, you won't use "A" or "Z" as part IDs once we have hierarchical part numbers, but consider them placeholders). if parts F or Z are ever going to be useful (e.g. to some external process that wants to validate the signature by hand), then the tool needs to provide some way of producing parts B and Y in a pristine form (that is, including MIME headers and without interpreting/applying any transfer encodings). Perhaps this means there are two flavors of "raw" that we should be distinguishing, something like: 0) "source" -- the equivalent to viewing the source of the message, with headers and without attempting to reverse transfer-encodings, etc. 1) "rare" -- (not entirely raw, but still bloody, ha ha) strip headers, reverse transfer encodings, etc. I think our current implementation of --format=raw emits "source" when applied to the entire message, but "rare" when applied to one of the parts. I'm suggesting that it might be useful to be able to get "source" of a part. (and perhaps it might also be useful to get the whole message "rare" sometimes?) My first instinct was: if it's multipart, provide "source", if it's single-part, provide "rare". But that fails for the XYZ case above -- we'd need Y (which is single-part) to be provided as "source" if we were ever to be able to make use of Z on its own, so i don't think it'll be that simple. OTOH, i'm not sure that "rare" is particularly meaningful for non-leaf parts. > Daniel, is this the problem that you're getting at with "opacity"? the origin of the term "opaque" used in this context can be found in the definition of multipart/signed: https://tools.ietf.org/html/rfc1847#section-2.1 > That if you ask for a multipart, you should effectively get a slice > out of the original message bytes (since multipart/* parts can't have > non-identity transfer encodings). Are you also saying that should > extend to transfer encoded leaf parts, too? hmm. is it true that multipart/* parts can't have non-identity transfer encodings? that would simplify some things, but i don't have a reference handy that says it's the case. At any rate, i'm not sure it affects the need for being able to emit both "rare" and "source" forms of at least the leaf (non-multipart) parts. i hope this is all at least somewhat clarifying and not just adding to the confusion, --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Do not attept to output part raw if part is not GMimePart.
Quoth Jameson Graef Rollins on Jun 27 at 2:44 pm: > On Mon, 27 Jun 2011 16:43:36 -0400, Austin Clements wrote: > > Just to clarify my understanding, --format=raw is only intended to > > work on either the whole message (special-cased in do_show_single) or > > a leaf MIME part, and in any other case, it will output nothing? The > > raw output test cases seem pretty thin. > > Hey, Austin. The raw part output works for *any* part, be it leaf part, > multipart, message/rfc822, etc. I added a bunch of tests for raw part > output that should cover all of this, although I don't think they've > been pulled into master yet. Oh, right, of course. show_message_part will walk into the parts, so format_part_content_raw will still be called on the leafs of a requested multipart. Though, this approach results in each leaf being transfer decoded and printed individually, so if you ask for a multipart, you won't get the "raw" contents of the multipart (unless it's part 0), so much as you get the concatenated "raw" contents of each part in the multipart. Daniel, is this the problem that you're getting at with "opacity"? That if you ask for a multipart, you should effectively get a slice out of the original message bytes (since multipart/* parts can't have non-identity transfer encodings). Are you also saying that should extend to transfer encoded leaf parts, too? > I think there are a lot of open questions about what should be output > for multipart raw. We should output _something_, though. I think we > can fix all of this up for 0.7, based on the work you've already done, > after 0.6 is released. Yes, hopefully. That's why I'm making sure I understand the issues here. ]:--8) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Drafts being tagged as inbox
My drafts (created using emacs message mode) are being tagged as inbox. However, they are not tagged as drafts. This is because emacs message mode does not store drafts in Maildir format, so there are no Maildir flags (e.g. D for draft) to sync tags with. Now, I could simply store drafts somewhere else, but then I wouldn't be able to search them using notmuch. Is there another way to have drafts correctly tagged? Thanks, Robin Green ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Do not attept to output part raw if part is not GMimePart.
On Mon, 27 Jun 2011 16:43:36 -0400, Austin Clements wrote: > Just to clarify my understanding, --format=raw is only intended to > work on either the whole message (special-cased in do_show_single) or > a leaf MIME part, and in any other case, it will output nothing? The > raw output test cases seem pretty thin. Hey, Austin. The raw part output works for *any* part, be it leaf part, multipart, message/rfc822, etc. I added a bunch of tests for raw part output that should cover all of this, although I don't think they've been pulled into master yet. I think there are a lot of open questions about what should be output for multipart raw. We should output _something_, though. I think we can fix all of this up for 0.7, based on the work you've already done, after 0.6 is released. jamie. pgpQYw4Fq2Dl2.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Do not attept to output part raw if part is not GMimePart.
On Mon, 27 Jun 2011 16:43:36 -0400, Austin Clements wrote: > Just to clarify my understanding, --format=raw is only intended to > work on either the whole message (special-cased in do_show_single) or > a leaf MIME part, and in any other case, it will output nothing? The > raw output test cases seem pretty thin. Hey, Austin. The raw part output works for *any* part, be it leaf part, multipart, message/rfc822, etc. I added a bunch of tests for raw part output that should cover all of this, although I don't think they've been pulled into master yet. I think there are a lot of open questions about what should be output for multipart raw. We should output _something_, though. I think we can fix all of this up for 0.7, based on the work you've already done, after 0.6 is released. 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/20110627/0bef3f1e/attachment-0001.pgp>
Re: [PATCH] fix sum moar typos
On Fri, 24 Jun 2011 22:04:13 +0200, Pieter Praet wrote: > You however, seem to be incredibly disciplined in this respect, > so statistically speaking, you're destined to become typo-king, > and you have every reason to be *proud* of it. :D Thanks for the compliment (even if sideways)! I enjoyed the laugh. > The only thing you could possibly have to be embarrassed about, > is insufficient laziness (which, for programmers, is considered a > virtue) ;) And thanks as well for the gentle chiding. I hope to benefit from it. -Carl -- carl.d.wo...@intel.com pgpUiZt6wlmGi.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] fix sum moar typos
On Fri, 24 Jun 2011 22:04:13 +0200, Pieter Praet wrote: > You however, seem to be incredibly disciplined in this respect, > so statistically speaking, you're destined to become typo-king, > and you have every reason to be *proud* of it. :D Thanks for the compliment (even if sideways)! I enjoyed the laugh. > The only thing you could possibly have to be embarrassed about, > is insufficient laziness (which, for programmers, is considered a > virtue) ;) And thanks as well for the gentle chiding. I hope to benefit from it. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110627/e24e6641/attachment.pgp>
Re: [RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"
On Fri, 24 Jun 2011 22:34:03 +0200, Louis Rilling wrote: > Maybe the alternate solution could consist in simply not renaming emails > having > no flags to be changed (Currently notmuch_message_tags_to_maildir_flags() > unconditionally moves messages from new/ to cur/). This would even lead to a > shorter patch :) Do you think that this would be acceptable? That could very well be acceptable. A user would have to carefully configure notmuch to get this behavior. Options for that could include the following in ~/.notmuch-config: [maildir] synchronize_flags=false Or: [new] tags= I think that if either of the above options are set that notmuch won't need to change the message's filename. And in that case, I would feel that it wouldn't be entirely unreasonable for notmuch to leave message in the "new" directory. This allows the user to effectively setup a mail-store that notmuch treats as more-or-less "read only" and that seems like a useful thing. Please experiment with that and feel free to send the patch or patches that you generate. Thanks again, and I hope you can find a way to make notmuch work for you. -Carl pgpnXQtogBjHY.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"
On Fri, 24 Jun 2011 22:34:03 +0200, Louis Rilling wrote: > Maybe the alternate solution could consist in simply not renaming emails > having > no flags to be changed (Currently notmuch_message_tags_to_maildir_flags() > unconditionally moves messages from new/ to cur/). This would even lead to a > shorter patch :) Do you think that this would be acceptable? That could very well be acceptable. A user would have to carefully configure notmuch to get this behavior. Options for that could include the following in ~/.notmuch-config: [maildir] synchronize_flags=false Or: [new] tags= I think that if either of the above options are set that notmuch won't need to change the message's filename. And in that case, I would feel that it wouldn't be entirely unreasonable for notmuch to leave message in the "new" directory. This allows the user to effectively setup a mail-store that notmuch treats as more-or-less "read only" and that seems like a useful thing. Please experiment with that and feel free to send the patch or patches that you generate. Thanks again, and I hope you can find a way to make notmuch work for you. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110627/76c92c7b/attachment.pgp>
Re: [PATCH] Do not attept to output part raw if part is not GMimePart.
On 06/27/2011 04:43 PM, Austin Clements wrote: > Just to clarify my understanding, --format=raw is only intended to > work on either the whole message (special-cased in do_show_single) or > a leaf MIME part, and in any other case, it will output nothing? The > raw output test cases seem pretty thin. I personally think that --format=raw *should* work on non-leaf parts; i don't know if that was the original intent. > (BTW, I believe the show restructuring I have under way should both > lift this restriction and eliminate the special case.) I hope the tests for this feature can eventually include some weird compound parts with whitespace-wrapped header lines, odd MIME delimiters, character encodings, etc. It would be really good if the --part=whatever --format=raw output produces byte-for-byte identical streams. Both PGP/MIME and S/MIME signatures rely on explicit opacity of the signed MIME parts, so being able to retrieve the signed data precisely would be quite useful for weird corner cases. --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test:Folder tags shouldn't match after removal of file in given folder
On Mon, Jun 27, 2011 at 1:12 PM, Mark Anderson wrote: > +test_begin_subtest "Test matches folder:spam" > +output=$(notmuch search folder:spam) > +test_expect_equal "$output" "thread:0001 2001-01-05 [1/1] > Notmuch Test Suite; Test message #1 (inbox unread)" > + > +sleep 1; I assume this has to do with directory mtime's. Is it sufficient to instead increment_mtime $dir/spam after the rm below? > + > +test_begin_subtest "Remove folder:spam copy of email" > +rm $dir/spam/$(basename $file_x) > +output=$(NOTMUCH_NEW) > +test_expect_equal "$output" "No new mail. Detected 1 file rename." ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test:Improve test behaviors when --root is used
This looks great (modulo one bug, below). I've wanted to run the
tests on tmpfs before, but was too lazy to actually fix the tests.
Given how easy it is to accidentally use "..", I wonder if there's a
way to force people to use $TEST_DIRECTORY?
On Mon, Jun 27, 2011 at 12:09 PM, Mark Anderson wrote:
> --- a/test/symbol-hiding
> +++ b/test/symbol-hiding
> @@ -12,13 +12,13 @@ test_description='exception symbol hiding'
> . ./test-lib.sh
>
> run_test(){
> - result=$(LD_LIBRARY_PATH=../../lib ./symbol-test 2>&1)
> + result=$(LD_LIBRARY_PATH=$TEST_DIRECTORY/../../lib ./symbol-test 2>&1)
Did you mean $TEST_DIRECTORY/../lib?
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Do not attept to output part raw if part is not GMimePart.
On Mon, Jun 27, 2011 at 1:07 PM, Jameson Graef Rollins wrote: > On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth wrote: >> I'd like to investigate this case a little bit to help answer the >> question of whether "notmuch should have done anything in this case". > > Hi, Carl. You can see this error if you try to output raw a multipart/* > or message/rfc822 part, ie: > > servo:~ 0$ notmuch show --part=1 --format=raw > id:"87wrgccedd@yoom.home.cworth.org" >/dev/null > > (process:29838): GLib-GObject-WARNING **: invalid cast from > `GMimeMultipartSigned' to `GMimePart' > > (process:29838): gmime-CRITICAL **: g_mime_part_get_content_object: assertion > `GMIME_IS_PART (mime_part)' failed > servo:~ 0$ > > Gmime seems to be successfully casting the part into GMimePart and then > outputting the content, but it does produce the warning on stderr. Just to clarify my understanding, --format=raw is only intended to work on either the whole message (special-cased in do_show_single) or a leaf MIME part, and in any other case, it will output nothing? The raw output test cases seem pretty thin. (BTW, I believe the show restructuring I have under way should both lift this restriction and eliminate the special case.) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: use emacsclient(1) for Emacs tests
On Mon, Jun 27, 2011 at 4:22 PM, Dmitry Kurochkin wrote: > On Mon, 27 Jun 2011 16:02:12 -0400, Austin Clements wrote: >> The trap is there just to cleanly shut down in case of a normal >> exit [1]. > > For normal exit we should just put this into test_done. Otherwise it is > not a normal exit and we do not care about Emacs error message. No? Yes, that's good, too, and it avoids the standard pitfalls of trap. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: use emacsclient(1) for Emacs tests
On Mon, 27 Jun 2011 16:02:12 -0400, Austin Clements wrote:
> This looks like a great idea! The test suite has been getting irritating
> slow.
>
> A few minor comments: This patch would be clearer if it the
> setq-to-let translation were a separate patch. It would also be worth
> adding a big comment at the top of the test explaining why all of the
> tests let-bind everything instead of setq'ing, primarily for the
> benefit of people writing new tests.
>
Agreed, will separate and add the warning.
> I might just be having trouble reading the patch, but the difference
> between emacs_start and emacs_server_start seems unclear. Perhaps the
> comments should explain how somebody would use these scripts?
>
emacs_start start a normal Emacs in non-daemon mode. Something you
might prefer when debugging.
>
> My bigger concern with this change is that it may leave behind stale
> emacs daemons if the script gets interrupted.
That is an issue indeed. I would probably do smth like a periodic check
inside Emacs that the shell is alive, but your approach below looks more
reliable.
> The only way I know to
> reliably kill a child process is to open a pipe to it and have it exit
> on its own when it reads EOF. Unfortunately, I couldn't find a way to
> do this with an emacs daemon (it appears daemon mode aggressively
> cleans up things like pipes), but here's a different approach:
>
> coproc emacs --batch --eval "(while t (eval (read)))"
> EMACSFD=${COPROC[1]}
> trap "echo '(kill-emacs)' >&$EMACSFD" EXIT
>
> echo '(message "Hi")' >&$EMACSFD
> # ...
>
> This is, basically, a poor man's emacs server, but the coprocess pipe
> binds it tightly to the shell. If the shell exits for *any* reason,
> the pipe will be closed by the kernel, emacs will read an EOF, and
> exit.
I like this idea.
> The trap is there just to cleanly shut down in case of a normal
> exit [1].
For normal exit we should just put this into test_done. Otherwise it is
not a normal exit and we do not care about Emacs error message. No?
> This also has the advantage that read-from-minibuffer still
> works:
>
> echo '(message (read-from-minibuffer ""))' >&$EMACSFD
> echo 'Test' >&$EMACSFD
>
> Thoughts?
>
I like it and I will implement it. Thanks for the idea.
Regards,
Dmitry
> [1] If you don't do this, emacs complains that it can't read from
> stdin before it exits. It would be nice to catch this condition in
> the elisp code and not bother with the trap, but the error thrown is
> just an 'error, so I don't think we can catch and ignore it without
> catching and ignoring *all* errors.
>
> On Sun, Jun 26, 2011 at 11:54 PM, Dmitry Kurochkin
> wrote:
> > Before the change, every Emacs tests ran in a separate Emacs
> > instance. Starting Emacs many times wastes considerable time and
> > it gets worse as the test suite grows. The patch solves this by
> > using a single Emacs server and emacsclient(1) to run multiple
> > tests. Emacs server is started on the first test_emacs call and
> > stopped when test_done is called or the test is killed by a
> > signal. Several auxiliary scripts useful for debugging and test
> > development are generated instead of the run_emacs script:
> >
> > * emacs_server_start - start Emacs server
> > * emacs_server_stop - stop Emacs server
> > * emacs_start - start Emacs
> > * emacs_run - execute ELisp expressions in running Emacs server
> >
> > Since multiple tests are run in a single Emacs instance, they
> > must not change Emacs environment because it may affect other
> > tests. For now, the only Emacs environment modifications done by
> > the tests are variable settings. Before the change, variables
> > were set with `setq' which affected other tests. The patch
> > changes all variables to use `let', so the scope of the change is
> > limited to a single test.
> > ---
> > test/emacs | 74 +-
> > test/test-lib.el | 6 ++
> > test/test-lib.sh | 149
> > ++---
> > 3 files changed, 161 insertions(+), 68 deletions(-)
> >
> > diff --git a/test/emacs b/test/emacs
> > index 4f16b41..f1939dc 100755
> > --- a/test/emacs
> > +++ b/test/emacs
> > @@ -12,20 +12,20 @@ test_emacs '(notmuch-hello)
> > test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
> >
> > test_begin_subtest "Saved search with 0 results"
> > -test_emacs '(setq notmuch-show-empty-saved-searches t)
> > - (setq notmuch-saved-searches
> > - '\''(("inbox" . "tag:inbox")
> > - ("unread" . "tag:unread")
> > - ("empty" . "tag:doesnotexist")))
> > - (notmuch-hello)
> > - (test-output)'
> > +test_emacs '(let ((notmuch-show-empty-saved-searches t)
> > + (notmuch-saved-searches
> > + '\''(("inbox" . "tag:inbox")
> > + ("unread" . "tag:unread")
> > + (
Re: [PATCH 2/2] test: use emacsclient(1) for Emacs tests
This looks like a great idea! The test suite has been getting irritating slow.
A few minor comments: This patch would be clearer if it the
setq-to-let translation were a separate patch. It would also be worth
adding a big comment at the top of the test explaining why all of the
tests let-bind everything instead of setq'ing, primarily for the
benefit of people writing new tests.
I might just be having trouble reading the patch, but the difference
between emacs_start and emacs_server_start seems unclear. Perhaps the
comments should explain how somebody would use these scripts?
My bigger concern with this change is that it may leave behind stale
emacs daemons if the script gets interrupted. The only way I know to
reliably kill a child process is to open a pipe to it and have it exit
on its own when it reads EOF. Unfortunately, I couldn't find a way to
do this with an emacs daemon (it appears daemon mode aggressively
cleans up things like pipes), but here's a different approach:
coproc emacs --batch --eval "(while t (eval (read)))"
EMACSFD=${COPROC[1]}
trap "echo '(kill-emacs)' >&$EMACSFD" EXIT
echo '(message "Hi")' >&$EMACSFD
# ...
This is, basically, a poor man's emacs server, but the coprocess pipe
binds it tightly to the shell. If the shell exits for *any* reason,
the pipe will be closed by the kernel, emacs will read an EOF, and
exit. The trap is there just to cleanly shut down in case of a normal
exit [1]. This also has the advantage that read-from-minibuffer still
works:
echo '(message (read-from-minibuffer ""))' >&$EMACSFD
echo 'Test' >&$EMACSFD
Thoughts?
[1] If you don't do this, emacs complains that it can't read from
stdin before it exits. It would be nice to catch this condition in
the elisp code and not bother with the trap, but the error thrown is
just an 'error, so I don't think we can catch and ignore it without
catching and ignoring *all* errors.
On Sun, Jun 26, 2011 at 11:54 PM, Dmitry Kurochkin
wrote:
> Before the change, every Emacs tests ran in a separate Emacs
> instance. Starting Emacs many times wastes considerable time and
> it gets worse as the test suite grows. The patch solves this by
> using a single Emacs server and emacsclient(1) to run multiple
> tests. Emacs server is started on the first test_emacs call and
> stopped when test_done is called or the test is killed by a
> signal. Several auxiliary scripts useful for debugging and test
> development are generated instead of the run_emacs script:
>
> * emacs_server_start - start Emacs server
> * emacs_server_stop - stop Emacs server
> * emacs_start - start Emacs
> * emacs_run - execute ELisp expressions in running Emacs server
>
> Since multiple tests are run in a single Emacs instance, they
> must not change Emacs environment because it may affect other
> tests. For now, the only Emacs environment modifications done by
> the tests are variable settings. Before the change, variables
> were set with `setq' which affected other tests. The patch
> changes all variables to use `let', so the scope of the change is
> limited to a single test.
> ---
> test/emacs | 74 +-
> test/test-lib.el | 6 ++
> test/test-lib.sh | 149 ++---
> 3 files changed, 161 insertions(+), 68 deletions(-)
>
> diff --git a/test/emacs b/test/emacs
> index 4f16b41..f1939dc 100755
> --- a/test/emacs
> +++ b/test/emacs
> @@ -12,20 +12,20 @@ test_emacs '(notmuch-hello)
> test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
>
> test_begin_subtest "Saved search with 0 results"
> -test_emacs '(setq notmuch-show-empty-saved-searches t)
> - (setq notmuch-saved-searches
> - '\''(("inbox" . "tag:inbox")
> - ("unread" . "tag:unread")
> - ("empty" . "tag:doesnotexist")))
> - (notmuch-hello)
> - (test-output)'
> +test_emacs '(let ((notmuch-show-empty-saved-searches t)
> + (notmuch-saved-searches
> + '\''(("inbox" . "tag:inbox")
> + ("unread" . "tag:unread")
> + ("empty" . "tag:doesnotexist"
> + (notmuch-hello)
> + (test-output))'
> test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
>
> test_begin_subtest "No saved searches displayed (all with 0 results)"
> -test_emacs '(setq notmuch-saved-searches
> - '\''(("empty" . "tag:doesnotexist")))
> - (notmuch-hello)
> - (test-output)'
> +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_begin_subtest "Basic notmuch-search view in emacs"
> @@ -147,9 +147,9 @@ output=$(notmuch search 'subject:"testing message sent
> via SMTP"' | notmuch
[PATCH] test:Folder tags shouldn't match after removal of file in given folder
Test for bug. Current stemming support for notmuch adds extra terms
to the DB which aren't removed when the file renames are detected.
When folder tags are added to a message, Xapian terms for both XFOLDER
and ZXFOLDER are generated. When one of the filenames are
renamed/removed, only the XFOLDER tags are removed, leaving it possible
for a match on a folder: tag that was previously but is no longer a
match in the maildir.
---
I found this bug last week. Essentially when the folder:spam tag is
added and puts the XFOLDERspam, it also inserts the ZXFOLDERspam. Then
if the mail is removed from the folder, it neglects to remove
ZXFOLDERspam.
This was detected with my offlineimap usage with gmail, still haven't
polished my personal folder/label transition. As I was looking into it,
I saw some unusual things flagged as spam, and investigated.
test/notmuch-test|1 +
test/search-folder-coherence | 48 ++
2 files changed, 49 insertions(+), 0 deletions(-)
create mode 100755 test/search-folder-coherence
diff --git a/test/notmuch-test b/test/notmuch-test
index fe85c6a..79e6267 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -41,6 +41,7 @@ TESTS="
maildir-sync
crypto
symbol-hiding
+ search-folder-coherence
"
TESTS=${NOTMUCH_TESTS:=$TESTS}
diff --git a/test/search-folder-coherence b/test/search-folder-coherence
new file mode 100755
index 000..cf3ba40
--- /dev/null
+++ b/test/search-folder-coherence
@@ -0,0 +1,48 @@
+#!/usr/bin/env bash
+test_description='folder tags removed and added through file renames remain
consistent'
+. ./test-lib.sh
+
+test_begin_subtest "No new messages"
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "No new mail."
+
+
+test_begin_subtest "Single new message"
+generate_message
+file_x=$gen_msg_filename
+id_x=$gen_msg_id
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "Added 1 new message to the database."
+
+test_begin_subtest "Add second folder for same message"
+dir=$(dirname $file_x)
+mkdir $dir/spam
+cp $file_x $dir/spam
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "No new mail."
+
+
+test_begin_subtest "Multiple files for same message"
+cat OUTPUT
+test_expect_equal_file OUTPUT EXPECTED
+
+test_begin_subtest "Test matches folder:spam"
+output=$(notmuch search folder:spam)
+test_expect_equal "$output" "thread:0001 2001-01-05 [1/1]
Notmuch Test Suite; Test message #1 (inbox unread)"
+
+sleep 1;
+
+test_begin_subtest "Remove folder:spam copy of email"
+rm $dir/spam/$(basename $file_x)
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "No new mail. Detected 1 file rename."
+
+test_begin_subtest "No mails match the folder:spam search"
+output=$(notmuch search folder:spam)
+test_expect_equal "$output" ""
+
+test_done
--
1.7.4.1
Re: Notmuch 0.6: Let's do it.
On Wed, 22 Jun 2011 22:26:06 -0300, David Bremner wrote: > 3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now >and July 1. Hi, David. You might want to consider applying the following patches for 0.6: Bug fix for raw output of gmime parts: id:"1307120466-4980-1-git-send-email-jroll...@finestructure.net" Series to fix rfc822 handling: id:"1307320169-29905-1-git-send-email-jroll...@finestructure.net" The later fixes what is probably consider a regression in rfc822 handling. I think we'll be able to improve this handling a lot in 0.7 (with the help of some work that Austin is doing), but these fixes should tide us over until then. jamie. pgp4q1arbjM0T.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Notmuch 0.6: Let's do it.
On Wed, 22 Jun 2011 22:26:06 -0300, David Bremner wrote: > 3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now >and July 1. Hi, David. You might want to consider applying the following patches for 0.6: Bug fix for raw output of gmime parts: id:"1307120466-4980-1-git-send-email-jrollins at finestructure.net" Series to fix rfc822 handling: id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net" The later fixes what is probably consider a regression in rfc822 handling. I think we'll be able to improve this handling a lot in 0.7 (with the help of some work that Austin is doing), but these fixes should tide us over until then. 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/20110627/370f1f32/attachment.pgp>
[PATCH] test:Folder tags shouldn't match after removal of file in given folder
Test for bug. Current stemming support for notmuch adds extra terms
to the DB which aren't removed when the file renames are detected.
When folder tags are added to a message, Xapian terms for both XFOLDER
and ZXFOLDER are generated. When one of the filenames are
renamed/removed, only the XFOLDER tags are removed, leaving it possible
for a match on a folder: tag that was previously but is no longer a
match in the maildir.
---
I found this bug last week. Essentially when the folder:spam tag is
added and puts the XFOLDERspam, it also inserts the ZXFOLDERspam. Then
if the mail is removed from the folder, it neglects to remove
ZXFOLDERspam.
This was detected with my offlineimap usage with gmail, still haven't
polished my personal folder/label transition. As I was looking into it,
I saw some unusual things flagged as spam, and investigated.
test/notmuch-test|1 +
test/search-folder-coherence | 48 ++
2 files changed, 49 insertions(+), 0 deletions(-)
create mode 100755 test/search-folder-coherence
diff --git a/test/notmuch-test b/test/notmuch-test
index fe85c6a..79e6267 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -41,6 +41,7 @@ TESTS="
maildir-sync
crypto
symbol-hiding
+ search-folder-coherence
"
TESTS=${NOTMUCH_TESTS:=$TESTS}
diff --git a/test/search-folder-coherence b/test/search-folder-coherence
new file mode 100755
index 000..cf3ba40
--- /dev/null
+++ b/test/search-folder-coherence
@@ -0,0 +1,48 @@
+#!/usr/bin/env bash
+test_description='folder tags removed and added through file renames remain
consistent'
+. ./test-lib.sh
+
+test_begin_subtest "No new messages"
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "No new mail."
+
+
+test_begin_subtest "Single new message"
+generate_message
+file_x=$gen_msg_filename
+id_x=$gen_msg_id
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "Added 1 new message to the database."
+
+test_begin_subtest "Add second folder for same message"
+dir=$(dirname $file_x)
+mkdir $dir/spam
+cp $file_x $dir/spam
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "No new mail."
+
+
+test_begin_subtest "Multiple files for same message"
+cat OUTPUT
+test_expect_equal_file OUTPUT EXPECTED
+
+test_begin_subtest "Test matches folder:spam"
+output=$(notmuch search folder:spam)
+test_expect_equal "$output" "thread:0001 2001-01-05 [1/1]
Notmuch Test Suite; Test message #1 (inbox unread)"
+
+sleep 1;
+
+test_begin_subtest "Remove folder:spam copy of email"
+rm $dir/spam/$(basename $file_x)
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "No new mail. Detected 1 file rename."
+
+test_begin_subtest "No mails match the folder:spam search"
+output=$(notmuch search folder:spam)
+test_expect_equal "$output" ""
+
+test_done
--
1.7.4.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test:Improve test behaviors when --root is used
Change add_email_corpus, emacs_deliver_message and tests to use
$TEST_DIRECTORY instead of '..'.
This improves the behavior of the usage of --root=, as the
assumption of '..' will be incorrect if the option is specified.
Document -root option in README and update valgrind to work with
-root.
---
I discovered the -root option when I wanted to run my test suite on
tmpfs, since my main drive is still spinning rust, and found test run
relocation is already implemented.
However, many tests were not well behaved when --root was specified,
which makes sense since it wasn't documented in the README, added in
this patch.
It seems like a good idea to try and run the test suite on a tmpfs
drive, but I don't know if there is a sufficiently generic standard
location or detection mechanism. I use /dev/shm/notmuch_test, which
works for me. I do wish I didn't have to keep specifying it, but I'm
not sure how well received putting this in notmuch's configure file
would be.
test/README|9 +
test/basic | 10 +-
test/crypto|2 +-
test/emacs |4 ++--
test/symbol-hiding |4 ++--
test/test-lib.sh | 18 +-
6 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/test/README b/test/README
index be75e0e..8fbf78d 100644
--- a/test/README
+++ b/test/README
@@ -41,6 +41,15 @@ The following command-line options are available when
running tests:
As the names depend on the tests' file names, it is safe to
run the tests with this option in parallel.
+--root=::
+ This runs the testsuites specified under a seperate directory.
+ However, caution is advised, as not all tests are maintained
+ with this relocation in mind, so some tests may behave
+ differently.
+
+ Pointing this argument at a tmpfs filesystem can improve the
+ speed of the test suite for some users.
+
When invoking the test suite via "make test" any of the above options
can be specified as follows:
diff --git a/test/basic b/test/basic
index d6e8c10..33bf711 100755
--- a/test/basic
+++ b/test/basic
@@ -51,9 +51,9 @@ test_expect_code 2 'failure to clean up causes the test to
fail' '
# Ensure that all tests are being run
test_begin_subtest 'Ensure that all available tests will be run by
notmuch-test'
-eval $(sed -n -e '/^TESTS="$/,/^"$/p' notmuch-test ../notmuch-test)
+eval $(sed -n -e '/^TESTS="$/,/^"$/p' notmuch-test
$TEST_DIRECTORY/notmuch-test)
tests_in_suite=$(for i in $TESTS; do echo $i; done | sort)
-available=$(ls -1 ../ | \
+available=$(ls -1 $TEST_DIRECTORY/ | \
sed -r -e
"/^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test)/d" \
-e
"/^(README|test-lib.sh|test-lib.el|test-results|tmp.*|valgrind|corpus*)/d" \
-e
"/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose|symbol-test.cc)/d"
\
@@ -63,19 +63,19 @@ available=$(ls -1 ../ | \
| sort)
test_expect_equal "$tests_in_suite" "$available"
-EXPECTED=../test.expected-output
+EXPECTED=$TEST_DIRECTORY/test.expected-output
suppress_diff_date() {
sed -e 's/\(.*\-\-\- test-verbose\.4\.\expected\).*/\1/' \
-e 's/\(.*\+\+\+ test-verbose\.4\.\output\).*/\1/'
}
test_begin_subtest "Ensure that test output is suppressed unless the test
fails"
-output=$(cd ..; ./test-verbose 2>&1 | suppress_diff_date)
+output=$(cd $TEST_DIRECTORY; ./test-verbose 2>&1 | suppress_diff_date)
expected=$(cat $EXPECTED/test-verbose-no | suppress_diff_date)
test_expect_equal "$output" "$expected"
test_begin_subtest "Ensure that -v does not suppress test output"
-output=$(cd ..; ./test-verbose -v 2>&1 | suppress_diff_date)
+output=$(cd $TEST_DIRECTORY; ./test-verbose -v 2>&1 | suppress_diff_date)
expected=$(cat $EXPECTED/test-verbose-yes | suppress_diff_date)
# Do not include the results of test-verbose in totals
rm $TEST_DIRECTORY/test-results/test-verbose-*
diff --git a/test/crypto b/test/crypto
index 01daffe..7eb3559 100755
--- a/test/crypto
+++ b/test/crypto
@@ -12,7 +12,7 @@ add_gnupg_home ()
local output
[ -d ${GNUPGHOME} ] && return
mkdir -m 0700 "$GNUPGHOME"
-gpg --no-tty --import <../gnupg-secret-key.asc >"$GNUPGHOME"/import.log
2>&1
+gpg --no-tty --import <$TEST_DIRECTORY/gnupg-secret-key.asc
>"$GNUPGHOME"/import.log 2>&1
test_debug "cat $GNUPGHOME/import.log"
if (gpg --quick-random --version >/dev/null 2>&1) ; then
echo quick-random >> "$GNUPGHOME"/gpg.conf
diff --git a/test/emacs b/test/emacs
index 6f82b08..f91078e 100755
--- a/test/emacs
+++ b/test/emacs
@@ -2,7 +2,7 @@
test_description="emacs interface"
. test-lib.sh
-EXPECTED=../emacs.expected-output
+EXPECTED=$TEST_DIRECTORY/emacs.expected-output
add_email_corpus
@@ -81,7 +81,7 @@ mkdir -p mail/sent/cur
mkdir -p mail/sent/new
mkdir -p mail/sent/tmp
-../smtp-dummy sent_message &
+$TEST_DIRECTORY/smtp-dummy sent_message &
smtp_dummy_pid=$!
test_emacs "(setq message-send-mail-function 'message-s
Re: [PATCH] Do not attept to output part raw if part is not GMimePart.
On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth wrote: > I'd like to investigate this case a little bit to help answer the > question of whether "notmuch should have done anything in this case". Hi, Carl. You can see this error if you try to output raw a multipart/* or message/rfc822 part, ie: servo:~ 0$ notmuch show --part=1 --format=raw id:"87wrgccedd@yoom.home.cworth.org" >/dev/null (process:29838): GLib-GObject-WARNING **: invalid cast from `GMimeMultipartSigned' to `GMimePart' (process:29838): gmime-CRITICAL **: g_mime_part_get_content_object: assertion `GMIME_IS_PART (mime_part)' failed servo:~ 0$ Gmime seems to be successfully casting the part into GMimePart and then outputting the content, but it does produce the warning on stderr. jamie. pgpkt4wvMyNal.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Do not attept to output part raw if part is not GMimePart.
On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth wrote: > I'd like to investigate this case a little bit to help answer the > question of whether "notmuch should have done anything in this case". Hi, Carl. You can see this error if you try to output raw a multipart/* or message/rfc822 part, ie: servo:~ 0$ notmuch show --part=1 --format=raw id:"87wrgccedd.fsf at yoom.home.cworth.org" >/dev/null (process:29838): GLib-GObject-WARNING **: invalid cast from `GMimeMultipartSigned' to `GMimePart' (process:29838): gmime-CRITICAL **: g_mime_part_get_content_object: assertion `GMIME_IS_PART (mime_part)' failed servo:~ 0$ Gmime seems to be successfully casting the part into GMimePart and then outputting the content, but it does produce the warning on stderr. 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/20110627/bbbcddd4/attachment-0001.pgp>
notmuch Digest, Vol 20, Issue 57
Hi all, I was wondering what a "best practice" would be in dealing with a gmail account and notmuch ? For instance, is this a possibility sync gmail tags with notmuch tags ? As fas as I am aware Gmail exposes its tags through imap folders, I am not too thrilled about the mixing of paradigms (folders vs tags) and it would be great if it could be aligned. -- Sander Boer -- "Architecture is the most fragile of all the media --it has a practical application as well as an artistic application... People demolish and change buildings all the time and an architect's work is destroyed, but you wouldn't think about altering a painting or music." --R. Venturi --
[PATCH] test:Improve test behaviors when --root is used
Change add_email_corpus, emacs_deliver_message and tests to use
$TEST_DIRECTORY instead of '..'.
This improves the behavior of the usage of --root=, as the
assumption of '..' will be incorrect if the option is specified.
Document -root option in README and update valgrind to work with
-root.
---
I discovered the -root option when I wanted to run my test suite on
tmpfs, since my main drive is still spinning rust, and found test run
relocation is already implemented.
However, many tests were not well behaved when --root was specified,
which makes sense since it wasn't documented in the README, added in
this patch.
It seems like a good idea to try and run the test suite on a tmpfs
drive, but I don't know if there is a sufficiently generic standard
location or detection mechanism. I use /dev/shm/notmuch_test, which
works for me. I do wish I didn't have to keep specifying it, but I'm
not sure how well received putting this in notmuch's configure file
would be.
test/README|9 +
test/basic | 10 +-
test/crypto|2 +-
test/emacs |4 ++--
test/symbol-hiding |4 ++--
test/test-lib.sh | 18 +-
6 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/test/README b/test/README
index be75e0e..8fbf78d 100644
--- a/test/README
+++ b/test/README
@@ -41,6 +41,15 @@ The following command-line options are available when
running tests:
As the names depend on the tests' file names, it is safe to
run the tests with this option in parallel.
+--root=::
+ This runs the testsuites specified under a seperate directory.
+ However, caution is advised, as not all tests are maintained
+ with this relocation in mind, so some tests may behave
+ differently.
+
+ Pointing this argument at a tmpfs filesystem can improve the
+ speed of the test suite for some users.
+
When invoking the test suite via "make test" any of the above options
can be specified as follows:
diff --git a/test/basic b/test/basic
index d6e8c10..33bf711 100755
--- a/test/basic
+++ b/test/basic
@@ -51,9 +51,9 @@ test_expect_code 2 'failure to clean up causes the test to
fail' '
# Ensure that all tests are being run
test_begin_subtest 'Ensure that all available tests will be run by
notmuch-test'
-eval $(sed -n -e '/^TESTS="$/,/^"$/p' notmuch-test ../notmuch-test)
+eval $(sed -n -e '/^TESTS="$/,/^"$/p' notmuch-test
$TEST_DIRECTORY/notmuch-test)
tests_in_suite=$(for i in $TESTS; do echo $i; done | sort)
-available=$(ls -1 ../ | \
+available=$(ls -1 $TEST_DIRECTORY/ | \
sed -r -e
"/^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test)/d" \
-e
"/^(README|test-lib.sh|test-lib.el|test-results|tmp.*|valgrind|corpus*)/d" \
-e
"/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose|symbol-test.cc)/d"
\
@@ -63,19 +63,19 @@ available=$(ls -1 ../ | \
| sort)
test_expect_equal "$tests_in_suite" "$available"
-EXPECTED=../test.expected-output
+EXPECTED=$TEST_DIRECTORY/test.expected-output
suppress_diff_date() {
sed -e 's/\(.*\-\-\- test-verbose\.4\.\expected\).*/\1/' \
-e 's/\(.*\+\+\+ test-verbose\.4\.\output\).*/\1/'
}
test_begin_subtest "Ensure that test output is suppressed unless the test
fails"
-output=$(cd ..; ./test-verbose 2>&1 | suppress_diff_date)
+output=$(cd $TEST_DIRECTORY; ./test-verbose 2>&1 | suppress_diff_date)
expected=$(cat $EXPECTED/test-verbose-no | suppress_diff_date)
test_expect_equal "$output" "$expected"
test_begin_subtest "Ensure that -v does not suppress test output"
-output=$(cd ..; ./test-verbose -v 2>&1 | suppress_diff_date)
+output=$(cd $TEST_DIRECTORY; ./test-verbose -v 2>&1 | suppress_diff_date)
expected=$(cat $EXPECTED/test-verbose-yes | suppress_diff_date)
# Do not include the results of test-verbose in totals
rm $TEST_DIRECTORY/test-results/test-verbose-*
diff --git a/test/crypto b/test/crypto
index 01daffe..7eb3559 100755
--- a/test/crypto
+++ b/test/crypto
@@ -12,7 +12,7 @@ add_gnupg_home ()
local output
[ -d ${GNUPGHOME} ] && return
mkdir -m 0700 "$GNUPGHOME"
-gpg --no-tty --import <../gnupg-secret-key.asc >"$GNUPGHOME"/import.log
2>&1
+gpg --no-tty --import <$TEST_DIRECTORY/gnupg-secret-key.asc
>"$GNUPGHOME"/import.log 2>&1
test_debug "cat $GNUPGHOME/import.log"
if (gpg --quick-random --version >/dev/null 2>&1) ; then
echo quick-random >> "$GNUPGHOME"/gpg.conf
diff --git a/test/emacs b/test/emacs
index 6f82b08..f91078e 100755
--- a/test/emacs
+++ b/test/emacs
@@ -2,7 +2,7 @@
test_description="emacs interface"
. test-lib.sh
-EXPECTED=../emacs.expected-output
+EXPECTED=$TEST_DIRECTORY/emacs.expected-output
add_email_corpus
@@ -81,7 +81,7 @@ mkdir -p mail/sent/cur
mkdir -p mail/sent/new
mkdir -p mail/sent/tmp
-../smtp-dummy sent_message &
+$TEST_DIRECTORY/smtp-dummy sent_message &
smtp_dummy_pid=$!
test_emacs "(setq message-send-mail-function
[PATCH 2/2] test: use emacsclient(1) for Emacs tests
Before the change, every Emacs tests ran in a separate Emacs
instance. Starting Emacs many times wastes considerable time and
it gets worse as the test suite grows. The patch solves this by
using a single Emacs server and emacsclient(1) to run multiple
tests. Emacs server is started on the first test_emacs call and
stopped when test_done is called or the test is killed by a
signal. Several auxiliary scripts useful for debugging and test
development are generated instead of the run_emacs script:
* emacs_server_start - start Emacs server
* emacs_server_stop - stop Emacs server
* emacs_start- start Emacs
* emacs_run - execute ELisp expressions in running Emacs server
Since multiple tests are run in a single Emacs instance, they
must not change Emacs environment because it may affect other
tests. For now, the only Emacs environment modifications done by
the tests are variable settings. Before the change, variables
were set with `setq' which affected other tests. The patch
changes all variables to use `let', so the scope of the change is
limited to a single test.
---
test/emacs | 74 +-
test/test-lib.el |6 ++
test/test-lib.sh | 149 ++---
3 files changed, 161 insertions(+), 68 deletions(-)
diff --git a/test/emacs b/test/emacs
index 4f16b41..f1939dc 100755
--- a/test/emacs
+++ b/test/emacs
@@ -12,20 +12,20 @@ test_emacs '(notmuch-hello)
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
test_begin_subtest "Saved search with 0 results"
-test_emacs '(setq notmuch-show-empty-saved-searches t)
- (setq notmuch-saved-searches
- '\''(("inbox" . "tag:inbox")
- ("unread" . "tag:unread")
- ("empty" . "tag:doesnotexist")))
- (notmuch-hello)
- (test-output)'
+test_emacs '(let ((notmuch-show-empty-saved-searches t)
+ (notmuch-saved-searches
+ '\''(("inbox" . "tag:inbox")
+ ("unread" . "tag:unread")
+ ("empty" . "tag:doesnotexist"
+ (notmuch-hello)
+ (test-output))'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
test_begin_subtest "No saved searches displayed (all with 0 results)"
-test_emacs '(setq notmuch-saved-searches
- '\''(("empty" . "tag:doesnotexist")))
- (notmuch-hello)
- (test-output)'
+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_begin_subtest "Basic notmuch-search view in emacs"
@@ -147,9 +147,9 @@ output=$(notmuch search 'subject:"testing message sent via
SMTP"' | notmuch_sear
test_expect_equal "$output" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite;
Testing message sent via SMTP (inbox)"
test_begin_subtest "notmuch-fcc-dirs set to nil"
-test_emacs "(setq notmuch-fcc-dirs nil)
- (notmuch-mua-mail)
- (test-output)"
+test_emacs "(let ((notmuch-fcc-dirs nil))
+ (notmuch-mua-mail)
+ (test-output))"
cat
[PATCH 1/2] test: use emacs_deliver_message in Emacs SMTP send test
Minor changes to expected results of other Emacs tests were
needed because the message Date header changed.
---
test/emacs | 34 +-
1 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/test/emacs b/test/emacs
index f3239ea..4f16b41 100755
--- a/test/emacs
+++ b/test/emacs
@@ -118,28 +118,12 @@ output=$(notmuch search 'id:"123..456 at example"' |
notmuch_search_sanitize)
test_expect_equal "$output" "thread:XXX 2001-01-05 [1/1] Notmuch Test Suite;
Message with .. in Message-Id (inbox search-add show-add)"
test_begin_subtest "Sending a message via (fake) SMTP"
-
-# Before we can send a message, we have to prepare the FCC maildir
-mkdir -p mail/sent/cur
-mkdir -p mail/sent/new
-mkdir -p mail/sent/tmp
-
-../smtp-dummy sent_message &
-smtp_dummy_pid=$!
-test_emacs "(setq message-send-mail-function 'message-smtpmail-send-it)
- (setq smtpmail-smtp-server \"localhost\")
- (setq smtpmail-smtp-service \"25025\")
- (notmuch-hello)
- (notmuch-mua-mail)
- (message-goto-to)
- (insert \"user at example.com\nDate: Fri, 29 Mar 1974 10:00:00
-\")
- (message-goto-subject)
- (insert \"Testing message sent via SMTP\")
- (message-goto-body)
- (insert \"This is a test that messages are sent via SMTP\")
- (message-send-and-exit)" >/dev/null 2>&1
-wait ${smtp_dummy_pid}
-
+emacs_deliver_message \
+'Testing message sent via SMTP' \
+'This is a test that messages are sent via SMTP' \
+'(message-goto-to)
+ (kill-whole-line)
+ (insert "To: user at example.com\n")'
sed \
-e s',^User-Agent: Notmuch/.* Emacs/.*,User-Agent: Notmuch/XXX Emacs/XXX,'
\
-e s',^Message-ID: <.*>$,Message-ID: ,' < sent_message >OUTPUT
@@ -147,7 +131,7 @@ cat /dev/null
output=$(notmuch search 'subject:"testing message sent via SMTP"' |
notmuch_search_sanitize)
-test_expect_equal "$output" "thread:XXX 1974-03-29 [1/1] Notmuch Test Suite;
Testing message sent via SMTP (inbox)"
+test_expect_equal "$output" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite;
Testing message sent via SMTP (inbox)"
test_begin_subtest "notmuch-fcc-dirs set to nil"
test_emacs "(setq notmuch-fcc-dirs nil)
@@ -262,7 +246,7 @@ Subject: Re: Testing message sent via SMTP
In-Reply-To:
Fcc: $(pwd)/mail/sent
--text follows this line--
-On Fri, 29 Mar 1974 10:00:00 -, Notmuch Test Suite wrote:
+On 01 Jan 2000 12:00:00 -, Notmuch Test Suite wrote:
> This is a test that messages are sent via SMTP
EOF
test_expect_equal_file OUTPUT EXPECTED
--
1.7.5.4
[PATCH 5/5] test: remove some sed(1) calls in Emacs tests
Few Emacs tests used sed(1) to remove unexpected output in the beginning to avoid getting confused by messages such as "Parsing /home/cworth/.mailrc... done". This is no longer needed since tests are run in a temporary home directory instead of the user's one. So remove these sed(1) calls. --- test/emacs |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/test/emacs b/test/emacs index fc4c01f..f3239ea 100755 --- a/test/emacs +++ b/test/emacs @@ -250,13 +250,10 @@ EOF test_expect_equal_file OUTPUT EXPECTED test_begin_subtest "Reply within emacs" -# We sed away everything before the ^From in the output to avoid getting -# confused by messages such as "Parsing /home/cworth/.mailrc... done" test_emacs '(notmuch-search "subject:\"testing message sent via SMTP\"") (notmuch-test-wait) (notmuch-search-reply-to-thread) (test-output)' -sed -i -ne '/^From/,$ p' OUTPUT sed -i -e 's/^In-Reply-To: <.*>$/In-Reply-To: /' OUTPUT cat
[PATCH 4/5] test: save buffer content to file instead of printing it in Emacs tests
Before the change, the common Emacs test scheme was to print
buffer content to stdout and redirect it to a file or capture it
in a shell variable. This does not work if we switch to using
emacsclient(1) for running the tests, because you can not print
to the stdout in this case. (Actually, you can print to stdout
from Emacs server, but you can not capture the output on
emacsclient(1)).
The patch introduces new Emacs test auxiliary functions:
`test-output' and `test-visible-output'. These functions are
used to save buffer content to a file directly from Emacs. For
most tests the changes are trivial, because Emacs stdout output
was redirected to a file anyway. But some tests captured the
output in a shell variable and compare it with the expected
output using test_expect_equal. These tests are changed to use
files and test_expect_equal_file instead.
Note: even if we do not switch Emacs tests to emacsclient(1), the
patch makes tests cleaner and is an improvement.
---
test/emacs | 71 ---
test/emacs-large-search-buffer | 23 +
test/test-lib.el | 10 ++
3 files changed, 62 insertions(+), 42 deletions(-)
diff --git a/test/emacs b/test/emacs
index 1e46c0d..fc4c01f 100755
--- a/test/emacs
+++ b/test/emacs
@@ -8,7 +8,7 @@ add_email_corpus
test_begin_subtest "Basic notmuch-hello view in emacs"
test_emacs '(notmuch-hello)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
test_begin_subtest "Saved search with 0 results"
@@ -18,20 +18,20 @@ test_emacs '(setq notmuch-show-empty-saved-searches t)
("unread" . "tag:unread")
("empty" . "tag:doesnotexist")))
(notmuch-hello)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
test_begin_subtest "No saved searches displayed (all with 0 results)"
test_emacs '(setq notmuch-saved-searches
'\''(("empty" . "tag:doesnotexist")))
(notmuch-hello)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file 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)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-search-tag-inbox
test_begin_subtest "Navigation of notmuch-hello to search results"
@@ -40,27 +40,30 @@ test_emacs '(notmuch-hello)
(re-search-forward "inbox")
(widget-button-press (point))
(notmuch-test-wait)
- (princ (buffer-string))' >OUTPUT
+ (test-output)'
test_expect_equal_file 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\")
- (princ (buffer-string))" >OUTPUT
+ (test-output)"
test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "notmuch-show for message with invalid From"
add_message "[subject]=\"message-with-invalid-from\"" \
"[from]=\"\\\"Invalid \\\" From\\\" \""
thread=$(notmuch search --output=threads subject:message-with-invalid-from)
-output=$(test_emacs "(notmuch-show \"$thread\") (princ (buffer-string))")
-test_expect_equal "$output" \
-'"Invalid " From" (2001-01-05) (inbox)
+test_emacs "(notmuch-show \"$thread\")
+ (test-output)"
+cat OUTPUT
+ (test-output)'
test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "Add tag from search view"
@@ -162,7 +165,7 @@ test_expect_equal "$output" "thread:XXX 1974-03-29 [1/1]
Notmuch Test Suite; T
test_begin_subtest "notmuch-fcc-dirs set to nil"
test_emacs "(setq notmuch-fcc-dirs nil)
(notmuch-mua-mail)
- (princ (buffer-string))" > OUTPUT
+ (test-output)"
cat
[PATCH 3/5] test: wrap and indent test_emacs calls
Most test_emacs calls have long arguments that consist of many
expressions. Putting them on a single line makes it hard to read
and produces poor diff when they are changed. The patch puts
every expression in test_emacs calls on a separate line.
---
test/emacs | 124 --
test/test-lib.sh | 14 ++-
2 files changed, 114 insertions(+), 24 deletions(-)
diff --git a/test/emacs b/test/emacs
index 6f82b08..1e46c0d 100755
--- a/test/emacs
+++ b/test/emacs
@@ -7,32 +7,51 @@ EXPECTED=../emacs.expected-output
add_email_corpus
test_begin_subtest "Basic notmuch-hello view in emacs"
-test_emacs '(notmuch-hello) (princ (buffer-string))' >OUTPUT
+test_emacs '(notmuch-hello)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello
test_begin_subtest "Saved search with 0 results"
-test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" . "tag:unread")
("empty" . "tag:doesnotexist"))) (notmuch-hello) (princ (buffer-string))'
>OUTPUT
+test_emacs '(setq notmuch-show-empty-saved-searches t)
+ (setq notmuch-saved-searches
+ '\''(("inbox" . "tag:inbox")
+ ("unread" . "tag:unread")
+ ("empty" . "tag:doesnotexist")))
+ (notmuch-hello)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-with-empty
test_begin_subtest "No saved searches displayed (all with 0 results)"
-test_emacs '(setq notmuch-saved-searches '\''(("empty" . "tag:doesnotexist")))
(notmuch-hello) (princ (buffer-string))' >OUTPUT
+test_emacs '(setq notmuch-saved-searches
+ '\''(("empty" . "tag:doesnotexist")))
+ (notmuch-hello)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file 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) (princ
(buffer-string))' >OUTPUT
+test_emacs '(notmuch-search "tag:inbox")
+ (notmuch-test-wait)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file OUTPUT $EXPECTED/notmuch-search-tag-inbox
test_begin_subtest "Navigation of notmuch-hello to search results"
-test_emacs '(notmuch-hello) (goto-char (point-min)) (re-search-forward
"inbox") (widget-button-press (point)) (notmuch-test-wait) (princ
(buffer-string))' >OUTPUT
+test_emacs '(notmuch-hello)
+ (goto-char (point-min))
+ (re-search-forward "inbox")
+ (widget-button-press (point))
+ (notmuch-test-wait)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file 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\") (princ
(buffer-string))" >OUTPUT
+test_emacs "(notmuch-show \"$maildir_storage_thread\")
+ (princ (buffer-string))" >OUTPUT
test_expect_equal_file OUTPUT $EXPECTED/notmuch-show-thread-maildir-storage
test_begin_subtest "notmuch-show for message with invalid From"
-add_message "[subject]=\"message-with-invalid-from\"" "[from]=\"\\\"Invalid
\\\" From\\\" \""
+add_message "[subject]=\"message-with-invalid-from\"" \
+ "[from]=\"\\\"Invalid \\\" From\\\" \""
thread=$(notmuch search --output=threads subject:message-with-invalid-from)
output=$(test_emacs "(notmuch-show \"$thread\") (princ (buffer-string))")
test_expect_equal "$output" \
@@ -44,33 +63,54 @@ Date: Tue, 05 Jan 2001 15:43:57 -
This is just a test message (#1)'
test_begin_subtest "Navigation of notmuch-search to thread view"
-test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait) (goto-char
(point-min)) (re-search-forward "Working with Maildir")
(notmuch-search-show-thread) (notmuch-test-wait) (princ (buffer-string))'
>OUTPUT
+test_emacs '(notmuch-search "tag:inbox")
+ (notmuch-test-wait)
+ (goto-char (point-min))
+ (re-search-forward "Working with Maildir")
+ (notmuch-search-show-thread)
+ (notmuch-test-wait)
+ (princ (buffer-string))' >OUTPUT
test_expect_equal_file 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)
-test_emacs "(notmuch-search \"$os_x_darwin_thread\") (notmuch-test-wait)
(notmuch-search-add-tag \"tag-from-search-view\")"
+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
[PATCH 2/5] test: cleanup test_emacs
Move auxiliary function definition and configuration from command line to test-lib.el. --- test/test-lib.el |8 test/test-lib.sh |9 + 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/test/test-lib.el b/test/test-lib.el index 9439996..344a02e 100644 --- a/test/test-lib.el +++ b/test/test-lib.el @@ -20,6 +20,14 @@ ;; ;; Authors: Dmitry Kurochkin +;; avoid crazy 10-column default of --batch +(set-frame-width (window-frame (get-buffer-window)) 80) + +(defun notmuch-test-wait () + "Wait for process completion." + (while (get-buffer-process (current-buffer)) +(sleep-for 0.1))) + (defun visible-buffer-string () "Same as `buffer-string', but excludes invisible text." (visible-buffer-substring (point-min) (point-max))) diff --git a/test/test-lib.sh b/test/test-lib.sh index 3ec388c..5f61960 100755 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -852,18 +852,11 @@ fi # --directory Ensure that the local elisp sources are found # # --load Force loading of notmuch.el and test-lib.el -# -# notmuch-test-waitFunction for tests to use to wait for process completion -# -# set-frame-width 80 columns (avoids crazy 10-column default of --batch) emacs \$BATCH --no-init-file --no-site-file \ --directory ../../emacs --load notmuch.el \ --directory .. --load test-lib.el \ - --eval "(defun notmuch-test-wait () - (while (get-buffer-process (current-buffer)) - (sleep-for 0.1)))" \ - --eval "(progn (set-frame-width (window-frame (get-buffer-window)) 80) \$@)" + --eval "(progn \$@)" EOF chmod a+x ./run_emacs ./run_emacs "$@" -- 1.7.5.4
[PATCH 1/5] test: do not set `message-signature' in test_emacs
It is no longer needed since tests are run in a temporary home directory instead of the user's one. --- test/test-lib.sh |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/test/test-lib.sh b/test/test-lib.sh index cc20f41..3ec388c 100755 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -855,8 +855,6 @@ fi # # notmuch-test-waitFunction for tests to use to wait for process completion # -# message-signatureAvoiding appending user's signature on messages -# # set-frame-width 80 columns (avoids crazy 10-column default of --batch) emacs \$BATCH --no-init-file --no-site-file \ @@ -865,7 +863,6 @@ emacs \$BATCH --no-init-file --no-site-file \ --eval "(defun notmuch-test-wait () (while (get-buffer-process (current-buffer)) (sleep-for 0.1)))" \ - --eval "(setq message-signature nil)" \ --eval "(progn (set-frame-width (window-frame (get-buffer-window)) 80) \$@)" EOF chmod a+x ./run_emacs -- 1.7.5.4
