Re: Printing mail
On Wed, 10 Nov 2010 08:32:01 +0100, Sebastian Spaeth wrote: > which gives me nice menu entries for previewing my printouts (defaults > to 'gv' but can easily be set to use 'evince') and which provides the > M-x pr-ps-buffer-preview command to invoke the print preview directly > (unfortunately it still asks about the n-up scaling of pages). Oh, but that doesn't print a message, it prints a buffer which may contain other stuff, and may have some elided lines. -- keith.pack...@intel.com pgp0t6AyJnX8g.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Printing mail
On Wed, 10 Nov 2010 08:32:01 +0100, Sebastian Spaeth wrote: > which gives me nice menu entries for previewing my printouts (defaults > to 'gv' but can easily be set to use 'evince') and which provides the > M-x pr-ps-buffer-preview command to invoke the print preview directly > (unfortunately it still asks about the n-up scaling of pages). Oh, but that doesn't print a message, it prints a buffer which may contain other stuff, and may have some elided lines. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101109/65be7225/attachment.pgp>
Re: Printing mail
On Tue, 09 Nov 2010 10:00:59 -0800, Keith Packard wrote: > I like the header formatting. And, using evince provides a 'friendly' > print dialog. But, yeah, something that dealt with mail encodings and > attachments would be even nicer. I have the printing package loaded (require 'printing) (pr-update-menus) which gives me nice menu entries for previewing my printouts (defaults to 'gv' but can easily be set to use 'evince') and which provides the M-x pr-ps-buffer-preview command to invoke the print preview directly (unfortunately it still asks about the n-up scaling of pages). Better header formatting could be achieved by locally customizing the "ps-print-header" thing when in notmuch mode. But I know too little about elisp to actually do that myself. That would actually be pretty nifty. Sebastian pgp99dCyNL8MB.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Show cleaner addresses during message display.
On Tue, 09 Nov 2010 15:53:49 -0500, Jameson Rollins wrote: > Hi, David. I am personally not interested in this collapse for a couple > of reasons. I really like seeing the full address that the mail comes > from. But what is the added benefit of "m...@foo.com" over m...@foo.com ? This is essentially a nonsense name that can just as well be left out... > I also don't like tooltips since I don't like using the mouse. > Is it possible to make this particular feature an option? If you don't use a mouse, how does the existence of tooltips annoy you? > I actually frequently yank this whole line to ease filling my address > book. But what is the point of having "m...@foo.com" in your address book, can't you just as well say "m...@foo.com" without loosing information? Anyway, I don't care strongly either way. I have just gotten very careful in adding new preferences rather than setting sensible defaults :). Sebastian pgpGW0NlSKqvZ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Second draft of logging patches
On Sun, 24 Oct 2010 18:01:02 -0300, david at tethera.net wrote: > Here is my second try at logging, taking into account the feedback I > got from Rob and Michal. There is definitely some tidying to do; in > particular I know the protoypes in public headers need > documentation. Also, I should add a configuration option to > enable configuration by command or something like that. I had a thought of a possibly interesting application of the (yet to be written) log playback code. It could be use to implement a simple queuing system where commands are only logged but not actually run on the database. I'm not sure about the performance implications, but it could be interesting because it eliminates the need to have a server running in order to eliminate write contention for the tag database. The "queue runner" could be as simple as a cron job, or it could be something spawned by one of the queue operations; the point would be that queueing could continue while the snapshot of the queue was run. d
Notmuch Ruby bindings
Andreas Amann writes: > After a number of embarrassing mails I use the attached patch, which > changes the default behaviour of "r" to "reply to sender only". Usual > reply to everybody is "R". Maybe you prefer reversed binding? At least in gnus: r - start reply to author R - start reply to author, including a copy of the original f - start reply to all F - start reply to all, including a copy of the original I believe f/F probably respect Mail-Followup-To. FWIW -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Notmuch Ruby bindings
Andreas Amann writes: > After a number of embarrassing mails I use the attached patch, which > changes the default behaviour of "r" to "reply to sender only". Usual > reply to everybody is "R". Maybe you prefer reversed binding? At least in gnus: r - start reply to author R - start reply to author, including a copy of the original f - start reply to all F - start reply to all, including a copy of the original I believe f/F probably respect Mail-Followup-To. FWIW -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Second draft of logging patches
On Sun, 24 Oct 2010 18:01:02 -0300, da...@tethera.net wrote: > Here is my second try at logging, taking into account the feedback I > got from Rob and Michal. There is definitely some tidying to do; in > particular I know the protoypes in public headers need > documentation. Also, I should add a configuration option to > enable configuration by command or something like that. I had a thought of a possibly interesting application of the (yet to be written) log playback code. It could be use to implement a simple queuing system where commands are only logged but not actually run on the database. I'm not sure about the performance implications, but it could be interesting because it eliminates the need to have a server running in order to eliminate write contention for the tag database. The "queue runner" could be as simple as a cron job, or it could be something spawned by one of the queue operations; the point would be that queueing could continue while the snapshot of the queue was run. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Correctly count the number of lines in a signature.
--- emacs/notmuch-wash.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 26a3f88..cfcfb21 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -145,7 +145,7 @@ is what to put on the button." (re-search-forward notmuch-wash-signature-regexp nil t)) (let* ((sig-start (match-beginning 0)) (sig-end (match-end 0)) -(sig-lines (1- (count-lines sig-start (point-max) +(sig-lines (count-lines sig-start (point-max (if (<= sig-lines notmuch-wash-signature-lines-max) (let ((sig-start-marker (make-marker)) (sig-end-marker (make-marker))) -- 1.7.2.3
[PATCH] emacs: Show cleaner addresses during message display.
Remove double quotes and flatten "foo at bar.com " to
"foo at bar.com". If the address is of the form "name ",
show only 'name' with a tooltip of the address.
---
More aggressive simplification and tooltips.
emacs/notmuch-show.el | 29 +++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 9e5d72d..098146b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -26,6 +26,7 @@
(require 'message)
(require 'mm-decode)
(require 'mailcap)
+(require 'mail-parse)
(require 'notmuch-lib)
(require 'notmuch-query)
@@ -198,12 +199,25 @@ any given message."
'face 'notmuch-tag-face)
")"))
+(defun notmuch-show-clean-address (parsed-address)
+ "Prepare a single email address for display."
+ (let ((address (car parsed-address))
+ (name (cdr parsed-address)))
+;; If the address is 'foo at bar.com ' then show just
+;; 'foo at bar.com'.
+(when (string= name address)
+ (setq name nil))
+(if name
+ (propertize name 'help-echo address)
+ address)))
+
(defun notmuch-show-insert-headerline (headers date tags depth)
"Insert a notmuch style headerline based on HEADERS for a
message at DEPTH in the current thread."
(let ((start (point)))
(insert (notmuch-show-spaces-n depth)
- (plist-get headers :From)
+ (notmuch-show-clean-address
+(mail-header-parse-address (plist-get headers :From)))
" ("
date
") ("
@@ -214,7 +228,18 @@ message at DEPTH in the current thread."
(defun notmuch-show-insert-header (header header-value)
"Insert a single header."
- (insert header ": " header-value "\n"))
+ (insert header ": "
+ (cond
+ ((or (string= "To" header)
+ (string= "Cc" header)
+ (string= "Bcc" header)
+ (string= "From" header))
+ (mapconcat 'notmuch-show-clean-address
+ (mail-header-parse-addresses header-value)
+ ", "))
+ (t
+ header-value))
+ "\n"))
(defun notmuch-show-insert-headers (headers)
"Insert the headers of the current message."
--
1.7.2.3
Printing mail
On Tue, 09 Nov 2010 06:51:12 -0800, "Keith Packard" wrote: > Here's a script I'm using with '|' to get mail printed. Cool script, thanks. Isn't invoking latex a bit heavy-handed to get a simple mail printed? Given that we are running in almighty emacs anyway. M-x ps-print buffer doesn't look too bad here and even copes with the encoding better than the printout of your mail with muttprint had looked. Not sure if we should bind a key to ps-print-buffer in notmuch by default? The only nuissane is that the title bar simply says "*Printing mail* (unsave)* here. Is there a way to customize that? Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101109/a12374e7/attachment-0001.pgp>
Re: [PATCH v4 0/4] Maildir synchronization
On Wed, 10 Nov 2010 00:39:31 +0100, Michal Sojka wrote:
> Did you try ./maildyr-sync -v?
Ah, no. That's always seemed really noisy. What I want is simply to see
the information related to a failure *when a failure occurs*, and not a
lot of noise, (nor having to re-run with extra options to see the output
I want).
> test_expect_success is not ideal though. Without -v, it should
> automatically show stdout when a test fails. I'll send patch for this in
> another mail.
Cool. I'll look for that.
> This only fails if the message is in */new and there is no */cur.
Right. I think that's a little too severe.
> I do not know if MH format has something special or it is just plain
> files in plain directories. If the latter, the synchronzation should
> work unless one of the directories is named 'new'.
The MH format is plain files in plain directories.
But in this case, I would contend that we don't _want_ the
synchronization to work. The files shouldn't be getting renamed at all
unless we are dealing with maildir.
Neither maildir nor mh give us anything extremely reliable that we can
use to unambiguously distinguish between them. But I think a heuristic
of:
if "cur" and "new" sub-directories exist:
then this directory is maildir;
And only when this heuristic passes should we be fiddling with filenames
in maildir-specified ways.
> If you think that what we have now is not sufficient, I'd need some help
> with this.
I'll look.
> P.S. Because of my work on test suite, I didn't do any additional tests
> for maildir synchronization, so maybe tomorrow :-(
No problem. I appreciate your help improving the test-suite
infrastructure!
Meanwhile, I ran into one problem with my proposal. We can't use
notmuch_message_sync_with_maildir_flags since notmuch_message_sync is an
internal interface. The corresponding public interface actually consists
of three or four different functions (notmuch_message_add_tag,
notmuch_message_remove_tag, and notmuch_message_freeze/thaw). I think it
would be quite crazy to add _with_maildir_flags variants of all of
those.
So maybe we will need a new function for the purpose of synchronizing
the current tags of a message to a maildir filename. So that would be,
perhaps, notmuch_message_tags_to_maildir_flags or so?
Finally, I'm also a bit unsettled about the handling of the "S"
flag. For all the other flags it is easy to document that
notmuch_database_add_message_with_maildir_flags simply adds the
corresponding tag to the message. But we can't say that the presence of
the "S" tag prevents this function from adding the "unread" tag, since
this function never does add an "unread" tag.
Instead, the setting of "unread" is taking place at a higher-level,
(inside "notmuch new"). So perhaps the right answer is for the library
function to add a "seen" tag, (making the handling of 'T' consistent
with all other tags and dropping the "inverse" field from the
table). Then, the "notmuch new" program can query the "seen" tag to
decide whether it should add its configured new_tags, ("inbox" and
"unread" by default).
I do want something like that anyway, because I want to make it so that
someone that first starts with notmuch and a large collection of maildir
messages doesn't end up with every message tagged as "inbox" after their
first run of "notmuch new".
So anyway, I'm currently working on implementing what I described
above. And I may change my mind slightly as I work through things.
I'll let you know,
-Carl
--
carl.d.wo...@intel.com
pgplHVp0vbK95.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v4 0/4] Maildir synchronization
On Wed, 10 Nov 2010 00:39:31 +0100, Michal Sojka wrote:
> Did you try ./maildyr-sync -v?
Ah, no. That's always seemed really noisy. What I want is simply to see
the information related to a failure *when a failure occurs*, and not a
lot of noise, (nor having to re-run with extra options to see the output
I want).
> test_expect_success is not ideal though. Without -v, it should
> automatically show stdout when a test fails. I'll send patch for this in
> another mail.
Cool. I'll look for that.
> This only fails if the message is in */new and there is no */cur.
Right. I think that's a little too severe.
> I do not know if MH format has something special or it is just plain
> files in plain directories. If the latter, the synchronzation should
> work unless one of the directories is named 'new'.
The MH format is plain files in plain directories.
But in this case, I would contend that we don't _want_ the
synchronization to work. The files shouldn't be getting renamed at all
unless we are dealing with maildir.
Neither maildir nor mh give us anything extremely reliable that we can
use to unambiguously distinguish between them. But I think a heuristic
of:
if "cur" and "new" sub-directories exist:
then this directory is maildir;
And only when this heuristic passes should we be fiddling with filenames
in maildir-specified ways.
> If you think that what we have now is not sufficient, I'd need some help
> with this.
I'll look.
> P.S. Because of my work on test suite, I didn't do any additional tests
> for maildir synchronization, so maybe tomorrow :-(
No problem. I appreciate your help improving the test-suite
infrastructure!
Meanwhile, I ran into one problem with my proposal. We can't use
notmuch_message_sync_with_maildir_flags since notmuch_message_sync is an
internal interface. The corresponding public interface actually consists
of three or four different functions (notmuch_message_add_tag,
notmuch_message_remove_tag, and notmuch_message_freeze/thaw). I think it
would be quite crazy to add _with_maildir_flags variants of all of
those.
So maybe we will need a new function for the purpose of synchronizing
the current tags of a message to a maildir filename. So that would be,
perhaps, notmuch_message_tags_to_maildir_flags or so?
Finally, I'm also a bit unsettled about the handling of the "S"
flag. For all the other flags it is easy to document that
notmuch_database_add_message_with_maildir_flags simply adds the
corresponding tag to the message. But we can't say that the presence of
the "S" tag prevents this function from adding the "unread" tag, since
this function never does add an "unread" tag.
Instead, the setting of "unread" is taking place at a higher-level,
(inside "notmuch new"). So perhaps the right answer is for the library
function to add a "seen" tag, (making the handling of 'T' consistent
with all other tags and dropping the "inverse" field from the
table). Then, the "notmuch new" program can query the "seen" tag to
decide whether it should add its configured new_tags, ("inbox" and
"unread" by default).
I do want something like that anyway, because I want to make it so that
someone that first starts with notmuch and a large collection of maildir
messages doesn't end up with every message tagged as "inbox" after their
first run of "notmuch new".
So anyway, I'm currently working on implementing what I described
above. And I may change my mind slightly as I work through things.
I'll let you know,
-Carl
--
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101109/2a7e0d8a/attachment.pgp>
[PATCH] emacs: Show cleaner addresses during message display.
On Tue, 9 Nov 2010 17:34:50 +, David Edmondson wrote: > Remove double quotes and flatten "foo at bar.com " to > "foo at bar.com". If the address is of the form "name ", > show only 'name' with a tooltip of the address. Hi, David. I am personally not interested in this collapse for a couple of reasons. I really like seeing the full address that the mail comes from. I also don't like tooltips since I don't like using the mouse. Is it possible to make this particular feature an option? I actually frequently yank this whole line to ease filling my address book. 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/20101109/151781f1/attachment.pgp>
[PATCH] test: Better handling of stdout and stderr
Git-style tests suppress stdout and stderr unless -v is given.
cworth-style tests (created by test_begin_subtest, test_expect_equal)
do not have this behavior so implement it the same.
Additionally, for both test styles, the test-lib.sh is changed so that
the content of suppressed stdout and stderr is shown in case of failed
test.
Finally a test for this functionality is added to basic tests
---
test/basic | 19 ++-
test/test-lib.sh | 21 +++--
test/test-verbose | 27 +++
test/test.expected-output/test-verbose-no | 20
test/test.expected-output/test-verbose-yes | 24
5 files changed, 104 insertions(+), 7 deletions(-)
create mode 100755 test/test-verbose
create mode 100644 test/test.expected-output/test-verbose-no
create mode 100644 test/test.expected-output/test-verbose-yes
diff --git a/test/basic b/test/basic
index 725c753..091dda0 100755
--- a/test/basic
+++ b/test/basic
@@ -52,9 +52,26 @@ 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'
tests_in_suite=$(grep TESTS= ../notmuch-test | sed -e "s/TESTS=\"\(.*\)\"/\1/"
| tr " " "\n" | sort)
-available=$(ls -1 ../ | grep -v -E
"^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test|README|test-lib.sh|test-results|tmp.*|valgrind|corpus*|emacs.expected-output|smtp-dummy|smtp-dummy.c)"
| sort)
+available=$(ls -1 ../ | grep -v -E
"^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test|README|test-lib.sh|test-results|tmp.*|valgrind|corpus*|emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose|test.expected-output)"
| sort)
test_expect_equal "$tests_in_suite" "$available"
+EXPECTED=../test.expected-output
+suppress_diff_date() {
+sed -e 's/\(.*\-\-\- test\.4\.\expected\).*/\1/' \
+ -e 's/\(.*\+\+\+ test\.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)
+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)
+expected=$(cat $EXPECTED/test-verbose-yes | suppress_diff_date)
+test_expect_equal "$output" "$expected"
+
+
# Test mail store prepared in test-lib.sh
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 8ecc9a0..3f69ab3 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -165,12 +165,6 @@ fi
echo $(basename "$0"): "Testing ${test_description}"
exec 5>&1
-if test "$verbose" = "t"
-then
- exec 4>&2 3>&1
-else
- exec 4>/dev/null 3>/dev/null
-fi
test_failure=0
test_count=0
@@ -393,6 +387,11 @@ add_email_corpus ()
test_begin_subtest ()
{
test_subtest_name="$1"
+# Remember stdout and stderr file descriptios and redirect test
+# output to the previously prepared file descriptors 3 and 4 (see
+# bellow)
+if test "$verbose" != "t"; then exec 4>test.output 3>&4; fi
+exec 6>&1 7>&2 >&3 2>&4
}
# Pass test if two arguments match
@@ -403,6 +402,7 @@ test_begin_subtest ()
# name.
test_expect_equal ()
{
+ exec 1>&6 2>&7 # Restore stdout and stderr
test "$#" = 3 && { prereq=$1; shift; } || prereq=
test "$#" = 2 ||
error "bug in the test script: not 2 or 3 parameters to
test_expect_equal"
@@ -498,6 +498,7 @@ test_failure_ () {
echo " $1"
shift
echo "$@" | sed -e 's/^//'
+ if test "$verbose" != "t"; then cat test.output; fi
test "$immediate" = "" || { GIT_EXIT_OK=t; exit 1; }
}
@@ -519,6 +520,7 @@ test_debug () {
test_run_ () {
test_cleanup=:
+ if test "$verbose" != "t"; then exec 4>test.output 3>&4; fi
eval >&3 2>&4 "$1"
eval_ret=$?
eval >&3 2>&4 "$test_cleanup"
@@ -908,6 +910,13 @@ EOF
# in subprocesses like git equals our $PWD (for pathname comparisons).
cd -P "$test" || error "Cannot setup test environment"
+if test "$verbose" = "t"
+then
+ exec 4>&2 3>&1
+else
+ exec 4>test.output 3>&4
+fi
+
this_test=${0##*/}
this_test=${this_test%%-*}
for skp in $NOTMUCH_SKIP_TESTS
diff --git a/test/test-verbose b/test/test-verbose
new file mode 100755
index 000..ea52f93
--- /dev/null
+++ b/test/test-verbose
@@ -0,0 +1,27 @@
+#!/bin/bash
+
+test_description='the verbosity options of the test framework itself.'
+
+. ./test-lib.sh
+
+test_expect_success 'print something in git-style test and pass' '
+ echo "hello stdout" &&
+ echo "hello stderr" >&2 &&
+ true
+'
+test_expect_success 'print something in git-style test and fail' '
+ echo "hello stdo
Re: [PATCH v4 0/4] Maildir synchronization
On Tue, 09 Nov 2010, Carl Worth wrote: > The updating I've done here only goes as far as just before "Add a > message to new/ without info". And it looks like one change I made > inadvertently broke a later test, so it's expected that "Check that > removing info did not change tags" currently fails. [And this failure > shows what I don't like about test_expect_success---if we were using > test_expect_equal it would be trivial to see what problem I made > here.] Did you try ./maildyr-sync -v? In fact, this is what I don't like about test_begin_subtest. test_begin_subtest does not hide debug output that goes to stdout and should only be shown with -v. I admit that test_expect_success is not ideal though. Without -v, it should automatically show stdout when a test fails. I'll send patch for this in another mail. > > Finally, when going through these tests I saw: > > "Removing of unread tag should fail without cur/" > > And that's behavior I do not want. Adding and removing tags should be > reliable whether or not the maildir synchronization can succeed. In this > specific case, the right answer is probably to say that a directory > without "new" and "cur" is not a maildir so no synchronization should be > done. This only fails if the message is in */new and there is no */cur. > Notmuch does need to be able to support things like mh format still. Do > the current patches break that by doing maildir-style renaming in > non-maildir directories? I do not know if MH format has something special or it is just plain files in plain directories. If the latter, the synchronzation should work unless one of the directories is named 'new'. See the tests with fakenew directory [fakenew is probably not the most obvious name for a simple non-maildir directory]. > If so, we'll need to fix that as well. And that might require an > "is_maildir" term to be stored for directory documents in the > database. > > Again, that's something I can help with. If you think that what we have now is not sufficient, I'd need some help with this. -Michal P.S. Because of my work on test suite, I didn't do any additional tests for maildir synchronization, so maybe tomorrow :-( ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Show cleaner addresses during message display.
On Tue, 9 Nov 2010 17:34:50 +, David Edmondson wrote: > Remove double quotes and flatten "f...@bar.com " to > "f...@bar.com". If the address is of the form "name ", > show only 'name' with a tooltip of the address. Hi, David. I am personally not interested in this collapse for a couple of reasons. I really like seeing the full address that the mail comes from. I also don't like tooltips since I don't like using the mouse. Is it possible to make this particular feature an option? I actually frequently yank this whole line to ease filling my address book. jamie. pgpZvJnNKVlKx.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v4 0/4] Maildir synchronization
On Tue, 09 Nov 2010 11:06:30 +0100, Michal Sojka wrote:
> This sounds good. Still it will be neccessary to synchronize with all
> files, not only the first one.
OK. I'll add that to the list of things I'll fix up.
> > I'd like to get things merged today, so I plan to take your patches and
> > then add new commits on top to implement the functions I described
> > above.
>
> Great! Seems that it is still not finished and I do not want to do
> duplicite work, so let me know what is the current status and whether
> you need some help from me (e.g. tests for multiple messages with same
> ID). I should be on IRC today.
Yesterday ended up being very busy, but I'm working on this stuff
now. My plan is to merge it and then release notmuch 0.5. (And yes, if I
had a more strict release manager then 0.5 would have been released
yesterday as-is---but it turns out my release manager had an equally
busy day yesterday).
If you wanted to write some more tests, then that would be very useful.
I've been changing the way the tests are written, so you might want to
look at the attached file to see what I'm doing and match it. Notable
differences:
* Using test_begin_subtest and test_expect_equal rather than the
list-of-commands to test_expect_success.
* Not emitting separate line-item results for things that are
already tested in other scripts, (like "add message" and
"search for message", etc.)
The updating I've done here only goes as far as just before "Add a
message to new/ without info". And it looks like one change I made
inadvertently broke a later test, so it's expected that "Check that
removing info did not change tags" currently fails. [And this failure
shows what I don't like about test_expect_success---if we were using
test_expect_equal it would be trivial to see what problem I made here.]
Finally, when going through these tests I saw:
"Removing of unread tag should fail without cur/"
And that's behavior I do not want. Adding and removing tags should be
reliable whether or not the maildir synchronization can succeed. In this
specific case, the right answer is probably to say that a directory
without "new" and "cur" is not a maildir so no synchronization should be
done.
Notmuch does need to be able to support things like mh format still. Do
the current patches break that by doing maildir-style renaming in
non-maildir directories? If so, we'll need to fix that as well. And that
might require an "is_maildir" term to be stored for directory documents
in the database.
Again, that's something I can help with.
Thanks again,
-Carl
pgpv1N1VKGoxk.pgp
Description: PGP signature
#!/bin/bash
test_description="maildir synchronization"
. ./test-lib.sh
# Much easier to examine differences if the "notmuch show
# --format=json" output includes some newlines. Also, need to avoid
# including the local value of MAIL_DIR in the result.
filter_show_json() {
sed -e 's/, /,\n/g' | sed -e "s|${MAIL_DIR}/|MAIL_DIR/|"
echo
}
cat >> "$NOTMUCH_CONFIG" < /dev/null
output=$(notmuch search tag:inbox | notmuch_search_sanitize)
output+="
"
mv "${gen_msg_filename}" "${gen_msg_filename}S"
increment_mtime "$(dirname "${gen_msg_filename}")"
output+=$(NOTMUCH_NEW)
output+="
"
output+=$(notmuch search tag:inbox | notmuch_search_sanitize)
test_expect_equal "$output" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite;
test message (inbox unread)
No new mail. Detected 1 file rename.
thread:XXX 2000-01-01 [1/1] Notmuch Test Suite; test message (inbox)"
test_begin_subtest "Adding message with 'S' flag prevents 'unread' tag"
add_message [subject]='"test message 2"' [date]='"Sat, 01 Jan 2000 12:00:00
-"' [filename]='"msg-002:2,S"' &&
output=$(notmuch search tag:inbox | notmuch_search_sanitize)
test_expect_equal "$output" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite;
test message (inbox)
thread:XXX 2000-01-01 [1/1] Notmuch Test Suite; test message 2 (inbox)"
test_begin_subtest "Adding 'replied' flag adds 'R' tag to filename"
notmuch tag +replied tag:inbox
output=$(ls -1 "${MAIL_DIR}")
test_expect_equal "$output" "msg-001:2,RS
msg-002:2,RS"
test_begin_subtest "notmuch show works with renamed file (without notmuch new)"
output=$(notmuch show --format=json id:msg-...@notmuch-test-suite |
filter_show_json)
test_expect_equal "$output" '[[[{"id": "msg-...@notmuch-test-suite",
"match": true,
"filename": "MAIL_DIR/msg-001:2,RS",
"timestamp": 946728000,
"date_relative": "2000-01-01",
"tags": ["inbox","replied"],
"headers": {"Subject": "test message",
"From": "Notmuch Test Suite ",
"To": "Notmuch Test Suite ",
"Cc": "",
"Bcc": "",
"Date": "Sat,
01 Jan 2000 12:00:00 -"},
"body": [{"id": 1,
"content-type": "text/plain",
"content": "This is just a test message (#1)\n"}]},
['
test_expect_success 'notmuch reply works with renamed file (without notmuch
new)' 'notmuch reply id:msg-...@notmuch-test-suite'
test_begin_subtest "notmuch new detects no file rename after ta
[PATCH v4 0/4] Maildir synchronization
On Tue, 09 Nov 2010 11:06:30 +0100, Michal Sojka wrote: > This sounds good. Still it will be neccessary to synchronize with all > files, not only the first one. OK. I'll add that to the list of things I'll fix up. > > I'd like to get things merged today, so I plan to take your patches and > > then add new commits on top to implement the functions I described > > above. > > Great! Seems that it is still not finished and I do not want to do > duplicite work, so let me know what is the current status and whether > you need some help from me (e.g. tests for multiple messages with same > ID). I should be on IRC today. Yesterday ended up being very busy, but I'm working on this stuff now. My plan is to merge it and then release notmuch 0.5. (And yes, if I had a more strict release manager then 0.5 would have been released yesterday as-is---but it turns out my release manager had an equally busy day yesterday). If you wanted to write some more tests, then that would be very useful. I've been changing the way the tests are written, so you might want to look at the attached file to see what I'm doing and match it. Notable differences: * Using test_begin_subtest and test_expect_equal rather than the list-of-commands to test_expect_success. * Not emitting separate line-item results for things that are already tested in other scripts, (like "add message" and "search for message", etc.) The updating I've done here only goes as far as just before "Add a message to new/ without info". And it looks like one change I made inadvertently broke a later test, so it's expected that "Check that removing info did not change tags" currently fails. [And this failure shows what I don't like about test_expect_success---if we were using test_expect_equal it would be trivial to see what problem I made here.] Finally, when going through these tests I saw: "Removing of unread tag should fail without cur/" And that's behavior I do not want. Adding and removing tags should be reliable whether or not the maildir synchronization can succeed. In this specific case, the right answer is probably to say that a directory without "new" and "cur" is not a maildir so no synchronization should be done. Notmuch does need to be able to support things like mh format still. Do the current patches break that by doing maildir-style renaming in non-maildir directories? If so, we'll need to fix that as well. And that might require an "is_maildir" term to be stored for directory documents in the database. Again, that's something I can help with. Thanks again, -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101109/47ba8da4/attachment.pgp> -- next part -- An embedded and charset-unspecified text was scrubbed... Name: maildir-sync URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101109/47ba8da4/attachment.txt> -- next part -- -- carl.d.worth at intel.com
[PATCH v4 0/4] Maildir synchronization
On Mon, 08 Nov 2010, Carl Worth wrote:
> On Sun, 07 Nov 2010 02:46:08 +0100, Michal Sojka
> wrote:
> > The current implementation renames only the file whose name is stored
> > first in the database. I have a TODO comment there to add a loop through
> > all file names, but I have never realized that deleted flag could be so
> > dangerous.
>
> I think what I'd like to do for now is to simply remove "deleted" from
> the set of tags being manipulated by this support.
This sounds good. Still it will be neccessary to synchronize with all
files, not only the first one. Currently, I experience a problem with
messages sent by myself to a list. The S flag is sometimes added to
the message in sent folder insted of to the message in inbox.
> This is the similar to what Sebastian decided to do with notmuchsync
> when he described in detail the same scenario I was concerned with:
>
> id:87eickhor1.fsf at SSpaeth.de
>
> Sebastian's solution was slightly different, ("deleted" was not
> synchronized by default but could be explicitly requested). I propose
> simply not synchronizing "deleted" until it can be made safe.
>
> > It will take me probably a few days until I find time to work on this.
> > So let me now in that time whether you have some preferences in the
> > above.
>
> I'd like to get things merged today, so I plan to take your patches and
> then add new commits on top to implement the functions I described
> above.
Great! Seems that it is still not finished and I do not want to do
duplicite work, so let me know what is the current status and whether
you need some help from me (e.g. tests for multiple messages with same
ID). I should be on IRC today.
-Michal
[PATCH] emacs: Correctly count the number of lines in a signature.
--- emacs/notmuch-wash.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 26a3f88..cfcfb21 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -145,7 +145,7 @@ is what to put on the button." (re-search-forward notmuch-wash-signature-regexp nil t)) (let* ((sig-start (match-beginning 0)) (sig-end (match-end 0)) -(sig-lines (1- (count-lines sig-start (point-max) +(sig-lines (count-lines sig-start (point-max (if (<= sig-lines notmuch-wash-signature-lines-max) (let ((sig-start-marker (make-marker)) (sig-end-marker (make-marker))) -- 1.7.2.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Printing mail
On Tue, 09 Nov 2010 17:16:48 +0100, Sebastian Spaeth wrote: > M-x ps-print buffer doesn't look too bad here and even copes with the > encoding better than the printout of your mail with muttprint had > looked. I like the header formatting. And, using evince provides a 'friendly' print dialog. But, yeah, something that dealt with mail encodings and attachments would be even nicer. -- keith.pack...@intel.com pgpMIVdu3cz0x.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Printing mail
On Tue, 09 Nov 2010 17:16:48 +0100, Sebastian Spaeth wrote: > M-x ps-print buffer doesn't look too bad here and even copes with the > encoding better than the printout of your mail with muttprint had > looked. I like the header formatting. And, using evince provides a 'friendly' print dialog. But, yeah, something that dealt with mail encodings and attachments would be even nicer. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101109/3ee054d4/attachment.pgp>
[PATCH] emacs: Show cleaner addresses during message display.
Remove double quotes and flatten "f...@bar.com " to
"f...@bar.com". If the address is of the form "name ",
show only 'name' with a tooltip of the address.
---
More aggressive simplification and tooltips.
emacs/notmuch-show.el | 29 +++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 9e5d72d..098146b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -26,6 +26,7 @@
(require 'message)
(require 'mm-decode)
(require 'mailcap)
+(require 'mail-parse)
(require 'notmuch-lib)
(require 'notmuch-query)
@@ -198,12 +199,25 @@ any given message."
'face 'notmuch-tag-face)
")"))
+(defun notmuch-show-clean-address (parsed-address)
+ "Prepare a single email address for display."
+ (let ((address (car parsed-address))
+ (name (cdr parsed-address)))
+;; If the address is 'f...@bar.com ' then show just
+;; 'f...@bar.com'.
+(when (string= name address)
+ (setq name nil))
+(if name
+ (propertize name 'help-echo address)
+ address)))
+
(defun notmuch-show-insert-headerline (headers date tags depth)
"Insert a notmuch style headerline based on HEADERS for a
message at DEPTH in the current thread."
(let ((start (point)))
(insert (notmuch-show-spaces-n depth)
- (plist-get headers :From)
+ (notmuch-show-clean-address
+(mail-header-parse-address (plist-get headers :From)))
" ("
date
") ("
@@ -214,7 +228,18 @@ message at DEPTH in the current thread."
(defun notmuch-show-insert-header (header header-value)
"Insert a single header."
- (insert header ": " header-value "\n"))
+ (insert header ": "
+ (cond
+ ((or (string= "To" header)
+ (string= "Cc" header)
+ (string= "Bcc" header)
+ (string= "From" header))
+ (mapconcat 'notmuch-show-clean-address
+ (mail-header-parse-addresses header-value)
+ ", "))
+ (t
+ header-value))
+ "\n"))
(defun notmuch-show-insert-headers (headers)
"Insert the headers of the current message."
--
1.7.2.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Printing mail
On Tue, 09 Nov 2010 06:51:12 -0800, "Keith Packard" wrote: > Here's a script I'm using with '|' to get mail printed. Cool script, thanks. Isn't invoking latex a bit heavy-handed to get a simple mail printed? Given that we are running in almighty emacs anyway. M-x ps-print buffer doesn't look too bad here and even copes with the encoding better than the printout of your mail with muttprint had looked. Not sure if we should bind a key to ps-print-buffer in notmuch by default? The only nuissane is that the title bar simply says "*Printing mail* (unsave)* here. Is there a way to customize that? Sebastian pgpYTr0U3P4OP.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Printing mail
Print is dead. Or so they say Here's a script I'm using with '|' to get mail printed. As you can see, it previews the mail on-screen with 'evince', from which you use the regular 'print' dialog. #!/bin/sh tmp=`mktemp` muttprint -p "TO_FILE:$tmp" evince $tmp rm $tmp Making this more secure would be nice. -- keith.pack...@intel.com pgpgkqMQnLV66.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Printing mail
Print is dead. Or so they say Here's a script I'm using with '|' to get mail printed. As you can see, it previews the mail on-screen with 'evince', from which you use the regular 'print' dialog. #!/bin/sh tmp=`mktemp` muttprint -p "TO_FILE:$tmp" evince $tmp rm $tmp Making this more secure would be nice. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101109/3bc6f467/attachment.pgp>
Re: [PATCH v4 0/4] Maildir synchronization
On Mon, 08 Nov 2010, Carl Worth wrote:
> On Sun, 07 Nov 2010 02:46:08 +0100, Michal Sojka wrote:
> > The current implementation renames only the file whose name is stored
> > first in the database. I have a TODO comment there to add a loop through
> > all file names, but I have never realized that deleted flag could be so
> > dangerous.
>
> I think what I'd like to do for now is to simply remove "deleted" from
> the set of tags being manipulated by this support.
This sounds good. Still it will be neccessary to synchronize with all
files, not only the first one. Currently, I experience a problem with
messages sent by myself to a list. The S flag is sometimes added to
the message in sent folder insted of to the message in inbox.
> This is the similar to what Sebastian decided to do with notmuchsync
> when he described in detail the same scenario I was concerned with:
>
> id:87eickhor1@sspaeth.de
>
> Sebastian's solution was slightly different, ("deleted" was not
> synchronized by default but could be explicitly requested). I propose
> simply not synchronizing "deleted" until it can be made safe.
>
> > It will take me probably a few days until I find time to work on this.
> > So let me now in that time whether you have some preferences in the
> > above.
>
> I'd like to get things merged today, so I plan to take your patches and
> then add new commits on top to implement the functions I described
> above.
Great! Seems that it is still not finished and I do not want to do
duplicite work, so let me know what is the current status and whether
you need some help from me (e.g. tests for multiple messages with same
ID). I should be on IRC today.
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] notmuch-deliver
On Mon, 08 Nov 2010 09:50:46 -0800, Carl Worth wrote: > On Wed, 26 May 2010 17:01:34 +0300, Ali Polatel wrote: > > notmuch-deliver is a maildir delivery tool for notmuch mail indexer. It > > reads from standard input, delivers the mail to the specified maildir > > and adds it to the notmuch database. This is meant as a convenient > > alternative to running notmuch new after mail delivery. > > Thanks for sharing this, Ali. You're welcome! > What's the best way to advertise this to potential users? Never thought about it honestly, I've just been using for sometime now and I'm quite happy with the results. > Should we include a separate utils directory in the notmuch repository > with auxiliary programs like this? Well, such programs should live in their own repositories. One big git repository with everything in it is just against the idea of distributed source control management imo. > Or should we implement this functionality within the notmuch binary > itself? We can think about this when the tool gets enough testing in my opinion. At this stage I don't think it's worth the hassle to include the functionality into the notmuch binary itself, but this is my personal opinion and I don't really know how many people in the outer-space uses this program. > I'm open to suggestions. Oh well, I'm open to more vodka. > If nothing else, the notmuchmail.org web page should grow a section to > point to auxiliary programs like this that users might find helpful. +1, but I won't be writing any documentation since I'm a mighty slacker. > Thanks again, You're welcome again! > -Carl > > -- > carl.d.worth at intel.com -- Regards, Ali Polatel -- 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/20101109/3057e81f/attachment.pgp>
