date:20120120

Hi Xavier,

On Fri, 20 Jan 2012 23:43:01 +0100, Xavier Maillard  
wrote:

> I like it.
Thanks for giving it a try.

> Simple but at first it is not easy to understand what to do with that
> window. Also, there is no way to toggle the window visibility. But for a
> first shot, it is a good shot :D

There could be a prompt in the minibuffer, I suppose, or the blank
second window could have a prompt in it as well.  And it would actually
be easy enough to add that toggle, since the window is really just a
different sort of view on a numerical list at the bottom of the
page. I'll give it a shot soon.

> I tried it by adding tach.el to myself. When sending the message, I have
> been asked whether I'd like to update copyright date and change licence
> to GPL3, huh ? Is this something specific to how tach.el works ?

I actually have no idea what this could come from. The date is a couple
of years back, and the license is GPL2+. I'm not sure why it would
prompt you to change that. Ever come across this before?

Best, 
Jesse

[PATCH] lib: Save filenames for files detected as "not an email file" in the database.

Later runs of "notmuch new" won't scan these files again and won't
print warnings.

Various programs (Dovecot, in my case) store indexes and caches and
such in the maildir.  Without this, notmuch persistently complains
about such files.
---
Every time I run notmuch new I get a slew of these warnings.  It was
starting to get on my nerves, so I implemented the solution suggested
by the TODO file.

 devel/TODO  |9 +++--
 lib/database.cc |   41 +
 test/new|   23 +++
 3 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/devel/TODO b/devel/TODO
index 4dda6f4..b64a26e 100644
--- a/devel/TODO
+++ b/devel/TODO
@@ -260,12 +260,9 @@ existing messages at the next database upgrade).
 Add support for the user to specify custom headers to be indexed (and
 re-index these for existing messages at the next database upgrade).

-Save filenames for files detected as "not an email file" in the
-database. This would allow for two things: 1. Optimizing "notmuch new"
-to not have to look at these files again (since they are potentially
-large so the detection could be potentially slow). 2. A "notmuch
-search" syntax could be added to allow the user to find these files,
-(and perhaps delete them or move them away as appropriate).
+Add a "notmuch search" syntax to allow uses to find files recorded as
+non-emails in the database (and perhaps delete them or move them away
+as appropriate).

 Fix filesystem/notmuch-new race condition by not updating database
 mtime for a directory if it is the same as the current mtime.
diff --git a/lib/database.cc b/lib/database.cc
index 8103bd9..fd1ec6e 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1618,6 +1618,43 @@ _notmuch_database_link_message (notmuch_database_t 
*notmuch,
 return NOTMUCH_STATUS_SUCCESS;
 }

+static notmuch_status_t
+_notmuch_database_add_nonemail (notmuch_database_t *notmuch,
+   const char *filename)
+{
+notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
+void *local = talloc_new (notmuch);
+char *term, *direntry;
+Xapian::docid id;
+
+if (notmuch->mode == NOTMUCH_DATABASE_MODE_READ_ONLY)
+   INTERNAL_ERROR ("Failure to ensure database is writable");
+
+Xapian::WritableDatabase *db =
+   static_cast  (notmuch->xapian_db);
+
+/* Create a document to record the non-email */
+Xapian::Document nonemail;
+term = talloc_asprintf (local, "%s%s", _find_prefix ("type"), "nonemail");
+nonemail.add_term (term, 0);
+
+status = _notmuch_database_filename_to_direntry (local, notmuch,
+filename, );
+if (status)
+   goto DONE;
+term = talloc_asprintf (local, "%s%s", _find_prefix ("file-direntry"),
+   direntry);
+nonemail.add_term (term, 0);
+
+/* Add it to the database */
+id = _notmuch_database_generate_doc_id (notmuch);
+db->replace_document (id, nonemail);
+
+  DONE:
+talloc_free (local);
+return status;
+}
+
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *notmuch,
  const char *filename,
@@ -1673,6 +1710,10 @@ notmuch_database_add_message (notmuch_database_t 
*notmuch,
(subject == NULL || *subject == '\0') &&
(to == NULL || *to == '\0'))
{
+   /* The file is not an email.  Record it so we don't
+* reconsider this file in the future, which prevents
+* potentially expensive scans and annoying warnings. */
+   _notmuch_database_add_nonemail (notmuch, filename);
ret = NOTMUCH_STATUS_FILE_NOT_EMAIL;
goto DONE;
}
diff --git a/test/new b/test/new
index 49f390d..346d453 100755
--- a/test/new
+++ b/test/new
@@ -153,4 +153,27 @@ rm -rf "${MAIL_DIR}"/two
 output=$(NOTMUCH_NEW)
 test_expect_equal "$output" "No new mail. Removed 3 messages."

+
+test_begin_subtest "Skips non-email"
+PRE_COUNT=$(notmuch search '*' | wc -l)
+echo "I am not an email" > "${MAIL_DIR}"/nonemail
+output=$(NOTMUCH_NEW 2>&1 | sed -n '/^Note:/p;$p' | sed 's/\(file:\) .*/\1 
XXX/')
+test_expect_equal "$output" "Note: Ignoring non-mail file: XXX
+No new mail."
+
+test_begin_subtest "Non-email files are not indexed"
+POST_COUNT=$(notmuch search '*' | wc -l)
+test_expect_equal "$PRE_COUNT" "$POST_COUNT"
+
+test_begin_subtest "Ignores non-email on second pass"
+touch "${MAIL_DIR}"
+output=$(NOTMUCH_NEW 2>&1 | sed -n '/^Note:/p;$p' | sed 's/\(file:\) .*/\1 
XXX/')
+test_expect_equal "$output" "No new mail."
+
+test_begin_subtest "Detects deletion of non-email"
+rm "${MAIL_DIR}"/nonemail
+output=$(NOTMUCH_NEW)
+test_expect_equal "$output" "No new mail. Removed 1 message."
+
+
 test_done
-- 
1.7.7.3

[PATCH v3 2/2] Silence buildbot warnings about unused results

On Thu, 19 Jan 2012 17:29:19 -0500, Austin Clements  wrote:
> This ignores the results of the two writes in sigint handlers even
> harder than before.
> 
> While my libc lacks the declarations that trigger these warnings, this
> can be tested by adding the following to notmuch.h:
> 
> __attribute__((warn_unused_result))
> ssize_t write(int fd, const void *buf, size_t count);
> ---

+1

Tomi

[PATCH v3 1/2] show: Handle read and write errors

On Thu, 19 Jan 2012 17:29:18 -0500, Austin Clements  wrote:
> For showing a message in raw format, rather than silently succeeding
> when a read or a write fails (or, probably, looping if a read fails),
> try to print an error message and exit with a non-zero status.
> 
> This silences one of the buildbot warnings about unused resuls.  While
> my libc lacks the declarations that trigger these warnings, this can
> be tested by adding the following to notmuch.h:
> 
> __attribute__((warn_unused_result))
> size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);
> ---

+1

Tomi

[PATCH 2/3] show: Use consistent header ordering in the text format

On Wed, 18 Jan 2012 15:28:26 -0500, Austin Clements  wrote:
> Previously, top-level message headers were printed as Subject, From,
> To, Date, while embedded message headers were printed From, To,
> Subject, Date.  This makes both cases use the former order and updates
> the tests accordingly.
> 
> Strangely, the raw format also uses this function, so this also fixes
> the two raw format tests affected by this change.
> ---

LGTM (this patch).

Tomi

[PATCH] Add pseudo-compatibility with gmime 2.6

On Fri, 20 Jan 2012 00:52:47 +0100, Thomas Jost  
wrote:
> 
> Here is how I did:
> 
>   (ldd notmuch | grep -q gmime-2.6) && test_subtest_known_broken
> 
> ldd notmuch will show "/path/to/libgmime-2.4.so.*" or
> "libgmime-2.6.so.*" so we can easily check this in the test suite.
> It's a little hacky but it seems to work. AFAIK ldd is a pretty standard
> tool so it should be available (almost) everywhere. However if you have
> a better idea I'll be glad to hear it.

The "hack" is good in a sense that if that check fails in any case
the test_subtest_known_broken is not executed and we get FAIL instead of
BROKEN.
The subshell is unneeded:

ldd notmuch | grep -q gmime-2.6 && test_subtest_known_broken

does the trick (potentially less forks)... ok now I have to test ;)

haha:
 $ rm xfoo.* xbar.*

 $ strace -ff -o xfoo sh -c '(ldd /bin/ls | grep -q libc) && echo foo'
 foo
 $ ls xfoo.*
 xfoo.14277  xfoo.14279  xfoo.14281  xfoo.14283  xfoo.14285
 xfoo.14278  xfoo.14280  xfoo.14282  xfoo.14284

 $ strace -ff -o xbar sh -c 'ldd /bin/ls | grep -q libc && echo foo'
 foo
 $ ls xbar.*
 xbar.14292  xbar.14294  xbar.14296  xbar.14298
 xbar.14293  xbar.14295  xbar.14297  xbar.14299


Tomi

[PATCH v4 1/3] show: don't use hex literals in JSON output

On Fri, 20 Jan 2012 07:55:03 -0400, David Bremner  wrote:
> On Fri, 20 Jan 2012 10:39:23 +0100, Thomas Jost  
> wrote:
> > JSON does not support hex literals (0x..) so numbers must be formatted as %d
> > instead of %x.
> > ---
> >  notmuch-show.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
>  
> Probably I'm just being lazy here, but can you explain why this change
> does not require a corresponding change on the emacs side?

Because Emacs already does the right thing. JSON numbers are supposed to
be decimal only (see http://json.org/: digits are 0-9 only), but the
current code could result in displaying a hexadecimal number instead
("c" instead of "12"). This would then trigger an error in Emacs, or in
any other correct JSON parser.

However we are quite lucky: because of the possible values of the gmime
error codes, such an error cannot happen.

The most common gmime error codes are 1 (expired signature), 2 (no
public key), 4 (expired key) and 8 (revoked key). The other possible
value is 16 (unsupported algorithm) but obviously it is much more rare.
If this happens, the current code will add '"errors": 10' (hex for
16...). This is valid JSON (it looks like a decimal number) but it is
incorrect (should be 16, not 10).

With this patch, notmuch will correctly display '"errors": 16' if such a
case happens.

(By the way, this issue was spotted by Austin Clements in
id:"20120117034714.GG16740 at mit.edu", so he deserves the credits :))

Regards,

-- 
Thomas/Schnouki
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120120/80917bba/attachment.pgp>

[PATCH v3] emacs: add invisible dot instead of space at the end of notmuch-hello search box

On Fri, 20 Jan 2012 00:52:14 +0100, Pieter Praet  wrote:
> From: Dmitry Kurochkin 
> 
> This makes `show-trailing-whitespace' happy, i.e. it does not mark the
> whole search box line as trailing spaces.
> 
> Since the dot is invisible, this change makes no visible difference
> for `notmuch-hello'.
> 
> Edited-by: Pieter Praet  to fix the tests.
> ---

+1

Tomi

Updated remote script

On Thu, 19 Jan 2012 15:31:02 -0500, Jesse Rosenthal  
wrote:
> Hi Tomi,
> 
> On Thu, 19 Jan 2012 19:50:38 +0200, Tomi Ollila  wrote:
> > Quick comments: "/tmp/notmuch_dtach.socket" is dangerous (and the _ssh).
> > 
> > either
> > make directory /tmp/notmuch_`id -u`
> > and chmod it to 0700
> > and make sure you own it and it has right permissions.
> > or
> > make directory for these sockets in $HOME and chmod that to 700
> > or
> > just drop the socket in $HOME/.ssh (which should already be
> > protected)
> 
> Thanks very much for that. I made some quick changes, based on your
> first suggestion above. I'm pretty sure the checks are not in the most
> optimal order, but it seemed worth getting the changes up.

Indeed!

> As always, of course, anyone is more than welcome to change and improve
> the version up there. I was mainly changing it just to get my last
> error-ridden version out of circulation.

I'll probably play with that in (far ;) future...

> 
> Thanks again,
> Jesse

Thanks, good script!

Tomi

tach.el: an attachment interface for message mode.

2012-01-20 Thread Aaron Ecay

Ha!  As I was recently looking at the MML stuff, I spent some time
googling around looking for this ? I knew I had seen a ?mutt-like?
attachment interface for emacs mail writing, but I couldn?t seem to come
across it.  I will definitely get it set up and play with it.  I don?t
have cause to attach files to email very often, but I?ll let you know
how it works out.

Thanks a lot,

-- 
Aaron Ecay

[PATCH 2/3] emacs: Don't return the button from `notmuch-show-insert-part-header'.

On Fri, 20 Jan 2012 09:43:31 +, David Edmondson  wrote:
> The buttons inserted for encrypted parts are slightly different now -
> previously the logic was that if a part was encrypted it would have
> the signature status inserted only if the encryption status was
> specified. Now the signature status will be inserted even without
> encryption status. My reading of the documentation says that this is
> correct, but I'm no expert. Comments?

I need some more time to review this patch, but I don't think this is
correct.  The signature status of encrypted messages (or even if the
message was signed at all) comes from the decryption process.  They're
not independent.  If the decryption fails it's unknown if there was a
signature or not.

I need to look closer at this, though.  Hopefully this weekend.

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/20120120/13bbc2fc/attachment.pgp>

[PATCH] Automatically exclude tags in notmuch-show

Quoth Mark Walters on Jan 20 at 12:10 am:
> 
> Ok Having said this is trivial I have found a problem. What should
> notmuch do if you do something like
> 
> notmuch show id:
> and that message is marked with a deleted tag? To be consistent with the
> other cases (where a deleted message is in a matched thread) we might
> want to return the message with the not-matched flag set (eg in
> JSON). But my patch doesn't, as it never even sees the thread since it
> doesn't match.
> 
> Looking at notmuch-show.c I think we should not apply the exclude tags
> to do_show_single, but usually should apply it to do_show. One solution
> which is simple and is at least close to right would be to get do_show
> to return the number of threads found. If this is zero then retry the
> query without the excludes (possible setting the match_flag to zero on
> each message since we know it does not match)
> 
> This is not a completely correct solution as if you ask notmuch-show to
> show more than one thread it might  threads which only contain deleted
> messages.
> 
> I can't see other good possibilities without slowing down the normal
> path a lot (eg find all threads that match the original query and then
> apply the argument above).
> 
> Any thoughts?

Oh dear.

Well, here's one idea.  Instead of doing a single thread query in
show, do a thread query without the exclusions and then a message
query with the exclusions.  Output all of the messages from the first
query, but use the results of the second query to determine which
messages are "matched".  The same could be accomplished in the library
somewhat more efficiently, but it's not obvious to me what the API
would be.

> Incidentally, is there something strange at the end of notmuch-show.c: I
> can't see how we could ever reach the last half dozen lines.

Yes, I've wondered about that before, too.  I think none of those
technically matter since they're all cleaning up resources that the OS
is about to clean up for us.  It would be a problem if the database
was open in write mode because Xapian's write lock hangs around for a
split second after the process terminates if you don't close the
database yourself, but in read mode it doesn't take any locks.  Not
that this excuses the code.

[PATCH] v2 emacs: colorize buttonized 'id:' links depending on the target message's state

2012-01-20 Thread Mark Anderson

On Wed, 18 Jan 2012 04:08:54 -0600, Pieter Praet  wrote:
> On Mon, 16 Jan 2012 16:43:06 -0500, Aaron Ecay  wrote:
> > On Mon, 16 Jan 2012 17:57:33 +0100, Pieter Praet  
> > wrote:
> > [...] Maybe you could change the regex that
> > matches id:?s to require a little more structure ? an at-sign, perhaps.
> > Or even requiring more than (say) 5 non-space characters after the
> > message id would cut down sharply on the false positive rate.
> > 
> 
> Not sure how that would pan out.  It's fairly common behaviour to put
> one or more spaces after a inline Message-Id, so I don't think such a
> limitation would be warmly recepted.

I thought this was a suggestion to have more than 5 non-space characters
after the id:, not the full id:LongIdThingHere 

It sounded to me like an attempt to prevent extra false positives and
the confusing buttonizing and notmuch queries that go with them.

-Mark

[PATCH v2] emacs: Make the part content available to the mm-inline* checks.

On Wed, 18 Jan 2012 14:35:01 -0500, Austin Clements  wrote:
> Shouldn't we only be doing this for parts with inline (or not
> attachment) content-disposition?  That's cheap to check.  Or do we
> actually want things like image attachments to get inlined, despite
> their disposition?

This is a good question, actually.  Should we just always ignore the
disposition, and inline stuff if it's inlinable?  Should this be
configurable?

The whole disposition thing is actually pretty confused in general, I
think.  I'm not sure if people realize this but parts that are
disposition "attachment" are not indexed by notmuch, even if they're
imminently indexable.  This seems wrong to me, as I would like to have
as much of the message indexed as possible, regardless of disposition.
I'm not sure what the original motivation was there.

I point this out because there's a kind of schizophrenia related to
disposition handling in general, and it might be worthwhile to clarify
how we expect them to be handled, both in terms of indexing and display.

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/20120120/0b975c05/attachment.pgp>

Improving notmuch query documentation [was: Re: Partial words on notmuch search?]

2012-01-20 Thread Mark Anderson

On Tue, 17 Jan 2012 16:29:23 -0600, Austin Clements  wrote:
> Quoth Andrei Popescu on Jan 18 at 12:14 am:
> > On Lu, 16 ian 12, 21:34:31, Austin Clements wrote:
> > > Quoth Andrei Popescu on Jan 16 at 10:21 pm:
> > > > Where can I read more about this? (except the source :)
> > > 
> > > Most of this is in the Xapian query syntax document you found.  Really
> > > we ought to beef-up Notmuch's query syntax documentation.
> > 
> > If I get around to write something myself where do you suggest I should 
> > start, the wiki or the manpage?
> 
> Probably expanding man/man7/notmuch-search-terms.7 would be the way to
> go.

I would appreciate it if the limitations of id: search were explained
there too.  I have some rules that I would love to make based on pattern
matching the message-id of the message, because I have a tool that
generates scads of email and I want to be able to delete a lot of it.

I think that id: is only matchable as an entire string, and a
confirmation of that would be nice to see.

For those who cringe when hearing the mention of _deletion_ of emails,
do you have a suggestion for how many copies of bugs in the bug database
I should store in my mail repository?  Note that IT only gives me a
couple gigabytes of home directory storage, and I don't have an SSD
Linux laptop, so the index does eventually slow down.

In other words, there are plenty of emails I love to forget ever having
received. :)

-Mark

tach.el: an attachment interface for message mode.

Dear All,

I sent this to the list a couple of years back, but now that things are
moving again, and there are new eyes on the list, I thought I'd send it
again. I believe I'm the only person to use this (and might well
continue to be so) but I've been using it for a couple of years without
any problems, and it has made using message mode a lot more
convenient. As far as I know, this doesn't intersect with the recent
security problems pointed out in mml-mode, but I could be wrong.

My issue was this: the handling of (outgoing) attachments in
message-mode left a lot to be desired. MML's markup can be confusing,
and can easily be edited by mistake.

Thus: tach.el. Tach is a minor mode that adds mutt-like attachment
handling to message mode. It's not notmuch specific, but I wrote it to
use with notmuch, and I thought it might be of use to some on the
list.

You can find tach.el attached to this email.

To use tach, put tach.el in your load-path, and add the following to
your .emacs:

(require 'tach)
(add-hook 'message-mode-hook 'tach-minor-mode)

Now when you type "C-c C-a" in message-mode, you should get a new window
with an attachment list. In that window, you can add and delete
attachments using `+' and `-', and scroll through them using the arrow
keys or the emacs direction commands.

tach.el will convert the attachments into MML markup as a last
step before sending. Hopefully you should never have to deal with it by
hand.

Some details: tach actually makes a numerical list at the bottom of the
message itself, separated by a custom separator. The message is narrowed
to above this separator, and the attachment window is an indirect buffer
narrowed to the region below the separator. The separator is erased when
the messages are translated to mml markup at the end.

This has remained at its earliest stages, and the usual disclaimers
apply. It certainly needs more a lot more commenting and
documentation. But I thought it might be useful, or at least fun to play
around with. And it might fill a niche for some users, as notmuch's
popularity continues to grow.

Best,
Jesse

-- next part --
A non-text attachment was scrubbed...
Name: tach.el
Type: application/emacs-lisp
Size: 9481 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20120120/62056761/attachment-0001.bin>

[PATCH] emacs: Make the part content available to `mm-inlinable-p'.

On Thu, 19 Jan 2012 09:34:07 +, David Edmondson  wrote:
> The `mm-inlinable-p' function works better if it has access to the
> data of the relevant part, so load that content before calling it.
> 
> Don't load the content for parts that the user has indicated no desire
> to inline.

So I'm a little confused here.  Is there some variable I need to set to
get inlinable stuff to display inline?  If so, I can't figure out what
it is.  I don't see anything relevant in notmuch config, and I'm not
finding anything in mm- either, although I'm not quite sure what I'm
looking for.

Currently I'm not getting any images displayed inline.  I used to get
some, but not all, but at the moment I'm just getting a little white box
with no image in it.  After applying this patch, I'm not getting any
attempt to inline images at all.  But I'm assuming there is some
variable I need to set that I haven't...

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/20120120/6d8fea84/attachment.pgp>

[PATCH v5] Make buttons for attachments allow viewing as well as saving

LGTM

Quoth Mark Walters on Jan 20 at  9:44 am:
> Define a keymap for attachment buttons to allow multiple actions.
> Define 3 possible actions:
> save attachment: exactly as currently,
> view attachment: uses mailcap entry,
> view attachment with user chosen program
> 
> Keymap on a button is: s for save, v for view and o for view with
> other program. Default (i.e. enter or mouse button) is save but this
> is configurable in notmuch customize.
> 
> One implementation detail: the view attachment function forces all
> attachments to be "displayed" using mailcap even if emacs could
> display them itself. Thus, for example, text/html appears in a browser
> and text/plain asks whether to save (on a standard debian setup)

[PATCH v4 3/3] Update NEWS and INSTALL about gmime 2.6

Quoth Thomas Jost on Jan 20 at 10:39 am:
> ---
>  INSTALL |   12 ++--
>  NEWS|9 +
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/INSTALL b/INSTALL
> index e51b397..bc98f1d 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -20,8 +20,8 @@ configure stage.
>  
>  Dependencies
>  
> -Notmuch depends on three libraries: Xapian, GMime 2.4, and Talloc
> -which are each described below:
> +Notmuch depends on three libraries: Xapian, GMime 2.4 or 2.6, and
> +Talloc which are each described below:
>  
>   Xapian
>   --
> @@ -39,14 +39,14 @@ which are each described below:
>   reading mail while notmuch would wait for Xapian when removing
>   the "inbox" and "unread" tags from messages in a thread.
>  
> - GMime 2.4
> - -
> - GMime 2.4 provides decoding of MIME email messages for Notmuch.
> + GMime 2.4 or 2.6
> + 
> + GMime provides decoding of MIME email messages for Notmuch.
>  
>   Without GMime, Notmuch would not be able to extract and index
>   the actual text from email message encoded as BASE64, etc.
>  
> - GMime 2.4 is available from http://spruce.sourceforge.net/gmime/
> + GMime is available from http://spruce.sourceforge.net/gmime/
>  
>   Talloc
>   --
> diff --git a/NEWS b/NEWS
> index 6afa912..e78472c 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -36,6 +36,15 @@ New functions
>notmuch_query_add_tag_exclude supports the new tag exclusion
>feature.
>  
> +Build fixes
> +---
> +
> +Compatibility with GMime 2.6
> +
> +  It is now possible to build notmuch against both GMime 2.4 and 2.6.
> +  However they may be some issues in PGP signature verification

Typo and comma: "However, there".  It would be good to describe the
bug, lest people hold off on upgrading because they think it's
something more dire.  Maybe

"However, a bug in current GMime 2.6 causes notmuch not to report
signatures where the signer key is unavailable (GNOME bug 668085)."

> +  because of a bug in current versions of GMime 2.6.
> +
>  Notmuch 0.11 (2012-01-13)
>  =
>

[PATCH v4 2/3] Add compatibility with gmime 2.6

LGTM!

Quoth Thomas Jost on Jan 20 at 10:39 am:
> There are lots of API changes in gmime 2.6 crypto handling. By adding
> preprocessor directives, it is however possible to add gmime 2.6 compatibility
> while preserving compatibility with gmime 2.4 too.
> 
> This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".
> 
> This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
> crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is
> currently broken (signature verification with signer key unavailable), most
> likely because of a bug in gmime which will hopefully be fixed in a future
> version.

[afew] announcing afew, an universal tagging solution with some fancy features

2012-01-20 Thread Justus Winter

Quoting Patrick Totzke (2012-01-20 11:40:41)
>Quoting Justus Winter (2011-12-21 08:53:23)
>>Hey Pazz,
>>
>>Quoting Patrick Totzke (2011-12-19 19:17:12)
>>>Also, should i not get some output when calling afew with -vv ?
>>
>>Yes you should ;). Here's an example run on my box:
>Alright, I do get logging output with upstream master thanks.
>
>FYI: I found the problem with afew not finding new mails on my box.
>I had the following in my ~/.notmuch-config:
>
>
>#   tagsA list (separated by ';') of the tags that will be
>#   added to all messages incorporated by "notmuch new".
>#
>[new]
>tags=new;
>
>I suspect you don't split the config value and thus afew ended up with a false 
>tag "new;".
>its just cosmetics but nevertheless..

Hm, actually it does exactly that:

def get_notmuch_new_tags():
return notmuch_settings.get('new', 'tags').split(';')

Could you post the relevant log messages?

>Thanks for afew! I translated my static filter rules and am very much enjoying 
>the automagic list-id tags :)
>/p

Cool :)

Cheers,
Justus

[afew] announcing afew, an universal tagging solution with some fancy features

2012-01-20 Thread Patrick Totzke

Quoting Justus Winter (2011-12-21 08:53:23)
>Hey Pazz,
>
>Quoting Patrick Totzke (2011-12-19 19:17:12)
>>Also, should i not get some output when calling afew with -vv ?
>
>Yes you should ;). Here's an example run on my box:
Alright, I do get logging output with upstream master thanks.

FYI: I found the problem with afew not finding new mails on my box.
I had the following in my ~/.notmuch-config:


#   tagsA list (separated by ';') of the tags that will be
#   added to all messages incorporated by "notmuch new".
#
[new]
tags=new;

I suspect you don't split the config value and thus afew ended up with a false 
tag "new;".
its just cosmetics but nevertheless..

Thanks for afew! I translated my static filter rules and am very much enjoying 
the automagic list-id tags :)
/p

[PATCH v4 3/3] Update NEWS and INSTALL about gmime 2.6

---
 INSTALL |   12 ++--
 NEWS|9 +
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/INSTALL b/INSTALL
index e51b397..bc98f1d 100644
--- a/INSTALL
+++ b/INSTALL
@@ -20,8 +20,8 @@ configure stage.

 Dependencies
 
-Notmuch depends on three libraries: Xapian, GMime 2.4, and Talloc
-which are each described below:
+Notmuch depends on three libraries: Xapian, GMime 2.4 or 2.6, and
+Talloc which are each described below:

Xapian
--
@@ -39,14 +39,14 @@ which are each described below:
reading mail while notmuch would wait for Xapian when removing
the "inbox" and "unread" tags from messages in a thread.

-   GMime 2.4
-   -
-   GMime 2.4 provides decoding of MIME email messages for Notmuch.
+   GMime 2.4 or 2.6
+   
+   GMime provides decoding of MIME email messages for Notmuch.

Without GMime, Notmuch would not be able to extract and index
the actual text from email message encoded as BASE64, etc.

-   GMime 2.4 is available from http://spruce.sourceforge.net/gmime/
+   GMime is available from http://spruce.sourceforge.net/gmime/

Talloc
--
diff --git a/NEWS b/NEWS
index 6afa912..e78472c 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,15 @@ New functions
   notmuch_query_add_tag_exclude supports the new tag exclusion
   feature.

+Build fixes
+---
+
+Compatibility with GMime 2.6
+
+  It is now possible to build notmuch against both GMime 2.4 and 2.6.
+  However they may be some issues in PGP signature verification
+  because of a bug in current versions of GMime 2.6.
+
 Notmuch 0.11 (2012-01-13)
 =

-- 
1.7.8.4

[PATCH v4 2/3] Add compatibility with gmime 2.6

There are lots of API changes in gmime 2.6 crypto handling. By adding
preprocessor directives, it is however possible to add gmime 2.6 compatibility
while preserving compatibility with gmime 2.4 too.

This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".

This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is
currently broken (signature verification with signer key unavailable), most
likely because of a bug in gmime which will hopefully be fixed in a future
version.
---
 mime-node.c  |   57 +++-
 notmuch-client.h |   30 -
 notmuch-reply.c  |7 
 notmuch-show.c   |   95 ++
 show-message.c   |4 ++
 test/crypto  |2 +
 6 files changed, 191 insertions(+), 4 deletions(-)

diff --git a/mime-node.c b/mime-node.c
index d26bb44..27077f7 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -33,7 +33,11 @@ typedef struct mime_node_context {
 GMimeMessage *mime_message;

 /* Context provided by the caller. */
+#ifdef GMIME_ATLEAST_26
+GMimeCryptoContext *cryptoctx;
+#else
 GMimeCipherContext *cryptoctx;
+#endif
 notmuch_bool_t decrypt;
 } mime_node_context_t;

@@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)

 notmuch_status_t
 mime_node_open (const void *ctx, notmuch_message_t *message,
-   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
-   mime_node_t **root_out)
+#ifdef GMIME_ATLEAST_26
+   GMimeCryptoContext *cryptoctx,
+#else
+   GMimeCipherContext *cryptoctx,
+#endif
+   notmuch_bool_t decrypt, mime_node_t **root_out)
 {
 const char *filename = notmuch_message_get_filename (message);
 mime_node_context_t *mctx;
@@ -112,12 +120,21 @@ DONE:
 return status;
 }

+#ifdef GMIME_ATLEAST_26
+static int
+_signature_list_free (GMimeSignatureList **proxy)
+{
+g_object_unref (*proxy);
+return 0;
+}
+#else
 static int
 _signature_validity_free (GMimeSignatureValidity **proxy)
 {
 g_mime_signature_validity_free (*proxy);
 return 0;
 }
+#endif

 static mime_node_t *
 _mime_node_create (const mime_node_t *parent, GMimeObject *part)
@@ -165,11 +182,25 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
GMimeMultipartEncrypted *encrypteddata =
GMIME_MULTIPART_ENCRYPTED (part);
node->decrypt_attempted = TRUE;
+#ifdef GMIME_ATLEAST_26
+   GMimeDecryptResult *decrypt_result = NULL;
+   node->decrypted_child = g_mime_multipart_encrypted_decrypt
+   (encrypteddata, node->ctx->cryptoctx, _result, );
+#else
node->decrypted_child = g_mime_multipart_encrypted_decrypt
(encrypteddata, node->ctx->cryptoctx, );
+#endif
if (node->decrypted_child) {
node->decrypt_success = node->verify_attempted = TRUE;
+#ifdef GMIME_ATLEAST_26
+   /* This may be NULL if the part is not signed. */
+   node->sig_list = g_mime_decrypt_result_get_signatures 
(decrypt_result);
+   if (node->sig_list)
+   g_object_ref (node->sig_list);
+   g_object_unref (decrypt_result);
+#else
node->sig_validity = 
g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
+#endif
} else {
fprintf (stderr, "Failed to decrypt part: %s\n",
 (err ? err->message : "no error explanation given"));
@@ -182,6 +213,15 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
 "(must be exactly 2)\n",
 node->nchildren);
} else {
+#ifdef GMIME_ATLEAST_26
+   node->sig_list = g_mime_multipart_signed_verify
+   (GMIME_MULTIPART_SIGNED (part), node->ctx->cryptoctx, );
+   node->verify_attempted = TRUE;
+
+   if (!node->sig_list)
+   fprintf (stderr, "Failed to verify signed part: %s\n",
+(err ? err->message : "no error explanation given"));
+#else
/* For some reason the GMimeSignatureValidity returned
 * here is not a const (inconsistent with that
 * returned by
@@ -200,12 +240,25 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
*proxy = sig_validity;
talloc_set_destructor (proxy, _signature_validity_free);
}
+#endif
}
 }

+#ifdef GMIME_ATLEAST_26
+/* sig_list may be created in both above cases, so we need to
+ * cleanly handle it here. */
+if (node->sig_list) {
+   GMimeSignatureList **proxy = talloc (node, GMimeSignatureList *);
+   *proxy = node->sig_list;
+   talloc_set_destructor (proxy, _signature_list_free);
+}
+#endif
+
+#ifndef GMIME_ATLEAST_26
 if (node->verify_attempted &&

[PATCH v4 1/3] show: don't use hex literals in JSON output

JSON does not support hex literals (0x..) so numbers must be formatted as %d
instead of %x.
---
 notmuch-show.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index d14dac9..91f566c 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -641,7 +641,7 @@ format_part_sigstatus_json (const GMimeSignatureValidity* 
validity)
printf (", \"keyid\": %s", json_quote_str (ctx_quote, 
signer->keyid));
}
if (signer->errors != GMIME_SIGNER_ERROR_NONE) {
-   printf (", \"errors\": %x", signer->errors);
+   printf (", \"errors\": %d", signer->errors);
}

printf ("}");
-- 
1.7.8.4

[PATCH v3 2/2] Add compatibility with gmime 2.6

> >  }
> >  
> > +#ifdef GMIME_ATLEAST_26
> > +static void
> > +format_part_sigstatus_json (GMimeSignatureList *siglist)
> > +{
> > +printf (", \"sigstatus\": [");
> > +
> > +if (!siglist) {
> > +   printf ("]");
> > +   return;
> > +}
> > +
> > +void *ctx_quote = talloc_new (NULL);
> > +int i;
> > +for (i = 0; i < g_mime_signature_list_length (siglist); i++) {
> > +   GMimeSignature *signature = g_mime_signature_list_get_signature 
> > (siglist, i);
> > +
> > +   if (i > 0)
> > +   printf (", ");
> > +
> > +   printf ("{");
> > +
> > +   /* status */
> > +   GMimeSignatureStatus status = g_mime_signature_get_status (signature);
> > +   printf ("\"status\": %s",
> > +   json_quote_str (ctx_quote,
> > +   signature_status_to_string (status)));
> > +
> > +   GMimeCertificate *certificate = g_mime_signature_get_certificate 
> > (signature);
> > +   if (status == GMIME_SIGNATURE_STATUS_GOOD) {
> > +   if (certificate)
> > +   printf (", \"fingerprint\": %s", json_quote_str (ctx_quote, 
> > g_mime_certificate_get_fingerprint (certificate)));
> > +   /* these dates are seconds since the epoch; should we
> > +* provide a more human-readable format string? */
> > +   time_t created = g_mime_signature_get_created (signature);
> > +   if (created != -1)
> > +   printf (", \"created\": %d", (int) created);
> > +   time_t expires = g_mime_signature_get_expires (signature);
> > +   if (expires > 0)
> > +   printf (", \"expires\": %d", (int) expires);
> > +   /* output user id only if validity is FULL or ULTIMATE. */
> > +   /* note that gmime is using the term "trust" here, which
> > +* is WRONG.  It's actually user id "validity". */
> > +   if (certificate) {
> > +   const char *name = g_mime_certificate_get_name (certificate);
> > +   GMimeCertificateTrust trust = g_mime_certificate_get_trust 
> > (certificate);
> > +   if (name && (trust == GMIME_CERTIFICATE_TRUST_FULLY || trust == 
> > GMIME_CERTIFICATE_TRUST_ULTIMATE))
> > +   printf (", \"userid\": %s", json_quote_str (ctx_quote, 
> > name));
> > +   }
> > +   } else if (certificate) {
> > +   const char *key_id = g_mime_certificate_get_key_id (certificate);
> > +   if (key_id)
> > +   printf (", \"keyid\": %s", json_quote_str (ctx_quote, key_id));
> > +   }
> > +
> > +   GMimeSignatureError errors = g_mime_signature_get_errors (signature);
> > +   if (errors != GMIME_SIGNATURE_ERROR_NONE) {
> > +   printf (", \"errors\": %d", errors);
> > +   }
> > +
> > +   printf ("}");
> > + }
> > +
> > +printf ("]");
> > +
> > +talloc_free (ctx_quote);
> > +}
> > +#else
> >  static void
> >  format_part_sigstatus_json (const GMimeSignatureValidity* validity)
> >  {
> > @@ -652,6 +739,7 @@ format_part_sigstatus_json (const 
> > GMimeSignatureValidity* validity)
> >  
> >  talloc_free (ctx_quote);
> >  }
> > +#endif
> >  
> >  static void
> >  format_part_content_json (GMimeObject *part)
> > @@ -990,13 +1078,20 @@ notmuch_show_command (void *ctx, unused (int argc), 
> > unused (char *argv[]))
> > } else if ((STRNCMP_LITERAL (argv[i], "--verify") == 0) ||
> >(STRNCMP_LITERAL (argv[i], "--decrypt") == 0)) {
> > if (params.cryptoctx == NULL) {
> > +#ifdef GMIME_ATLEAST_26
> > +   /* TODO: GMimePasswordRequestFunc */
> > +   if (NULL == (params.cryptoctx = g_mime_gpg_context_new(NULL, 
> > "gpg")))
> > +#else
> > GMimeSession* session = g_object_new(g_mime_session_get_type(), 
> > NULL);
> > if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session, 
> > "gpg")))
> > +#endif
> > fprintf (stderr, "Failed to construct gpg context.\n");
> > else
> > 
> > g_mime_gpg_context_set_always_trust((GMimeGpgContext*)params.cryptoctx, 
> > FALSE);
> > +#ifndef GMIME_ATLEAST_26
> > g_object_unref (session);
> > session = NULL;
> > +#endif
> > }
> > if (STRNCMP_LITERAL (argv[i], "--decrypt") == 0)
> > params.decrypt = 1;
> > diff --git a/show-message.c b/show-message.c
> > index 8768889..83ecf81 100644
> > --- a/show-message.c
> > +++ b/show-message.c
> > @@ -48,7 +48,11 @@ show_message_part (mime_node_t *node,
> > format->part_encstatus (node->decrypt_success);
> >  
> >  if (node->verify_attempted && format->part_sigstatus)
> > +#ifdef GMIME_ATLEAST_26
> > +   format->part_sigstatus (node->sig_list);
> > +#else
> > format->part_sigstatus (node->sig_validity);
> > +#endif
> >  
> >  format->part_content (part);
> >  
> > diff --git a/test/crypto b/test/crypto
> > index 0af4aa8..3779abc 100755
> > --- a/test/crypto
> > +++ b/test/crypto
> > @@ -104,6 +104,8 @@ test_expect_equal \
> >  "$expected"
> >  
> >  test_begin_subtest "signature verification with signer key unavailable"
> > +# this is broken with current versions of gmime-2.6
> > +(ldd $(which notmuch) | grep -q gmime-2.6) && test_subtest_known_broken
> 
> Just to be nitpicky, you should either escape the . in the regexp or
> pass -F to grep.  Otherwise I think this hack is fine (though it might
> have to get a little fancier once GMime fixes this bug).

Added -F :)

I guess we could also use pkg-config to test if gmime 2.6 is present. It
would also be simpler to test the version number once gmime fixes this
bug:

  pkg-config --atleast-version=2.6.x gmime-2.6 || test_subtest_known_broken

But this would mean assuming that notmuch is built against a system-wide
gmime. Or it would require setting PKG_CONFIG_PATH before tests...
Complicated.

So IMHO once gmime fixes this bug we should just remove the
test_subtest_known_broken and maybe add something like this in
notmuch-client.h:

  #ifdef GMIME_MAJOR_VERSION
  #define GMIME_ATLEAST_26
  #if !GMIME_CHECK_VERSION(2, 6, x)
  #warning "Building against an old and buggy version of gmime. Please update 
to 2.6.x."
  #endif
  #endif

> 
> >  # move the gnupghome temporarily out of the way
> >  mv "${GNUPGHOME}"{,.bak}
> >  output=$(notmuch show --format=json --verify subject:"test signed message 
> > 001" \

-- 
Thomas/Schnouki
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120120/ae25838f/attachment.pgp>

[PATCH] emacs: fix tests wrt notmuch-hello invisible dot

2012-01-20 Thread Dmitry Kurochkin

On Fri, 20 Jan 2012 00:50:49 +0100, Pieter Praet  wrote:
> On Fri, 20 Jan 2012 02:37:30 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > On Thu, 19 Jan 2012 22:31:14 +0100, Pieter Praet  
> > wrote:
> > > Not meant to be applied!
> > > 
> > > Should be merged into
> > >   id:"1326815734-20421-1-git-send-email-dmitry.kurochkin at gmail.com"
> > > 
> > 
> > Oops.  I managed to miss the failing tests.  I would send a new patch
> > version.
> > 
> 
> Sorry, yeah, that would probably have been a better idea.
> 
> Amended patch follows (let's hope `git send-email' does the right thing).
> 

Thanks!

Regards,
  Dmitry

> 
> > Regards,
> >   Dmitry
> > 
> > > ---
> > >  test/emacs.expected-output/notmuch-hello   |2 +-
> > >  .../notmuch-hello-no-saved-searches|2 +-
> > >  .../emacs.expected-output/notmuch-hello-with-empty |2 +-
> > >  3 files changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/test/emacs.expected-output/notmuch-hello 
> > > b/test/emacs.expected-output/notmuch-hello
> > > index de57de2..196112e 100644
> > > --- a/test/emacs.expected-output/notmuch-hello
> > > +++ b/test/emacs.expected-output/notmuch-hello
> > > @@ -4,7 +4,7 @@ Saved searches: [edit]
> > >  
> > > 52 inbox   52 unread
> > >  
> > > -Search:  
> > > 
> > > +Search:  
> > >.
> > >  
> > >  [Show all tags]
> > >  
> > > diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches 
> > > b/test/emacs.expected-output/notmuch-hello-no-saved-searches
> > > index f1fc4d6..f4cfe49 100644
> > > --- a/test/emacs.expected-output/notmuch-hello-no-saved-searches
> > > +++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches
> > > @@ -1,6 +1,6 @@
> > > Welcome to notmuch. You have 52 messages.
> > >  
> > > -Search:  
> > > 
> > > +Search:  
> > >.
> > >  
> > >  [Show all tags]
> > >  
> > > diff --git a/test/emacs.expected-output/notmuch-hello-with-empty 
> > > b/test/emacs.expected-output/notmuch-hello-with-empty
> > > index dd8728b..a860a72 100644
> > > --- a/test/emacs.expected-output/notmuch-hello-with-empty
> > > +++ b/test/emacs.expected-output/notmuch-hello-with-empty
> > > @@ -4,7 +4,7 @@ Saved searches: [edit]
> > >  
> > > 52 inbox   52 unread   0 empty 
> > >  
> > > -Search:  
> > > 
> > > +Search:  
> > >.
> > >  
> > >  [Show all tags]
> > >  
> > > -- 
> > > 1.7.8.1
> > > 
> 
> 
> Peace
> 
> -- 
> Pieter

[PATCH v3 5/5] emacs: Use message-citation-line-format in reply

2012-01-20 Thread Adam Wolfe Gordon

Erk, forgot to reply-all.  Aaron might get this twice.

On Thu, Jan 19, 2012 at 22:53, Aaron Ecay  wrote:
> (let ((message-citation-line-format
>   (remove ?\n message-citation-line-format)))
>  ...)
>
> (Or, if you think someone might have a newline other than at the end of
> the string, you could do something a little more complicated to remove
> only a newline at the end.)

I did something like this initially, to make the test pass, but my
thought is that some people might intend for that newline to be there
and we shouldn't be removing it.  Perhaps I'm being overly sensitive
to people with odd setups ;-).

> Or you could introduce a new defcustom
> ?notmuch-message-citation-line-format? (with newline-less default), and
> let-bind m-l-c-f to that value.  But that is pretty ugly ? we don?t want
> to have to ?wrap? every variable whose default we don?t like.

Agreed, not a good solution.

> I?m personally of the opinion that notmuch should just say ?the mail
> composition facility is provided by message mode (here is the
> documentation on customizing it)?.  Message mode is 8,000 lines of
> elisp.  We have the choice to:
> - write our own message composition mode
> - wrap (as explained above) the default message-mode variables we don?t
>  like in notmuch-prefixed variants, with suitable let-bindings.
> - use only the parts of message-mode that we like
> - pass composition off to message mode
>
> The first option just doesn?t make sense.  The second is also a little
> nuts.  The third is what we are trying now, but it?s painful ? the
> message mode code has its own structure and its own defaults, which
> don?t always agree with notmuch?s.  I am in favor of the fourth ?
> notmuch?s elisp code should pass data to message mode in the most low
> level form it can, and let message mode do any extra work in the way
> it already does.  And users should customize message composition via
> message mode, not notmuch.  There?s a tradeoff to this approach ? by
> controlling more within notmuch, we can have nicer defaults at the
> expense of more brittle code and/or fewer user-visible customizations.
>
> This is not in any way a criticism of your work (which is great) ?
> you?re right that you need ?permission? to uproot the defaults, and I?m
> advocating for it to be given.

I think we're on the same page here - I definitely prefer to have
notmuch-mua use existing emacs functionality wherever it makes sense.
The only question in my mind is how ugly we're willing to let the
defaults be in order to leverage existing stuff.

> One possible step that might ease the transition pain could be for
> notmuch?s emacs interface to have a configuration file (similar to
> Wanderlust?s ~/.wl; I believe Gnus also uses a ~/.gnus).  The idea is
> that this file contains elisp code, and is loaded by notmuch the first
> time any notmuch-related commands are invoked by the user.  If the file
> does not exist, notmuch could create it with default content that sets
> message-citation-function, message-citation-line-format,
> message-yank-prefix (to get rid of the ugly default whereby message-mode
> indents the original message by four spaces instead of inserting ?> ?),
> etc.  If there is interest in this approach, I?d be happy to work on a
> patch for it.

This would be a good way to get around the ugly defaults problem, and
it would also be an easy way for people to share their notmuch/emacs
setups.  I already have my setup in a file separate from my normal
emacs config, and I run `emacs -q -l ~/.emacs-notmuch -f notmuch` so
it doesn't load my normal, programming-oriented setup.

One additional issue I noticed this morning with using
message-cite-original: it doesn't wrap/fill the quoted message.  I'm
guessing there's a way to make message-cite-original do this, but I
haven't figured it out.

[PATCH v5] Make buttons for attachments allow viewing as well as saving

Define a keymap for attachment buttons to allow multiple actions.
Define 3 possible actions:
save attachment: exactly as currently,
view attachment: uses mailcap entry,
view attachment with user chosen program

Keymap on a button is: s for save, v for view and o for view with
other program. Default (i.e. enter or mouse button) is save but this
is configurable in notmuch customize.

One implementation detail: the view attachment function forces all
attachments to be "displayed" using mailcap even if emacs could
display them itself. Thus, for example, text/html appears in a browser
and text/plain asks whether to save (on a standard debian setup)
---
 emacs/notmuch-show.el |  116 ++--
 1 files changed, 92 insertions(+), 24 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index fc13462..6229432 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -112,6 +112,16 @@ indentation."
   :type 'boolean
   :group 'notmuch-show)

+(defcustom notmuch-show-part-button-default-action 'notmuch-show-save-part
+  "Default part header button action (on ENTER or mouse click)."
+  :group 'notmuch-show
+  :type '(choice (const :tag "Save part"
+   notmuch-show-save-part)
+(const :tag "View part"
+   notmuch-show-view-part)
+(const :tag "View interactively"
+   notmuch-show-interactively-view-part)))
+
 (defmacro with-current-notmuch-show-message ( body)
   "Evaluate body with current buffer set to the text of current message"
   `(save-excursion
@@ -283,10 +293,21 @@ message at DEPTH in the current thread."
(run-hooks 'notmuch-show-markup-headers-hook)

 (define-button-type 'notmuch-show-part-button-type
-  'action 'notmuch-show-part-button-action
+  'action 'notmuch-show-part-button-default
+  'keymap 'notmuch-show-part-button-map
   'follow-link t
   'face 'message-mml)

+(defvar notmuch-show-part-button-map
+  (let ((map (make-sparse-keymap)))
+(set-keymap-parent map button-map)
+(define-key map "s" 'notmuch-show-part-button-save)
+(define-key map "v" 'notmuch-show-part-button-view)
+(define-key map "o" 'notmuch-show-part-button-interactively-view)
+map)
+  "Submap for button commands")
+(fset 'notmuch-show-part-button-map notmuch-show-part-button-map)
+
 (defun notmuch-show-insert-part-header (nth content-type declared-type 
 name comment)
   (let ((button))
 (setq button
@@ -301,29 +322,58 @@ message at DEPTH in the current thread."
   " ]")
   :type 'notmuch-show-part-button-type
   :notmuch-part nth
-  :notmuch-filename name))
+  :notmuch-filename name
+  :notmuch-content-type content-type))
 (insert "\n")
 ;; return button
 button))

 ;; Functions handling particular MIME parts.

-(defun notmuch-show-save-part (message-id nth  filename)
-  (let ((process-crypto notmuch-show-process-crypto))
-(with-temp-buffer
-  (setq notmuch-show-process-crypto process-crypto)
-  ;; Always acquires the part via `notmuch part', even if it is
-  ;; available in the JSON output.
-  (insert (notmuch-show-get-bodypart-internal message-id nth))
-  (let ((file (read-file-name
-  "Filename to save as: "
-  (or mailcap-download-directory "~/")
-  nil nil
-  filename)))
-   ;; Don't re-compress .gz & al.  Arguably we should make
-   ;; `file-name-handler-alist' nil, but that would chop
-   ;; ange-ftp, which is reasonable to use here.
-   (mm-write-region (point-min) (point-max) file nil nil nil 
'no-conversion t)
+(defmacro notmuch-with-temp-part-buffer (message-id nth  body)
+  (declare (indent 2))
+  (let ((process-crypto (make-symbol "process-crypto")))
+`(let ((,process-crypto notmuch-show-process-crypto))
+   (with-temp-buffer
+(setq notmuch-show-process-crypto ,process-crypto)
+;; Always acquires the part via `notmuch part', even if it is
+;; available in the JSON output.
+(insert (notmuch-show-get-bodypart-internal ,message-id ,nth))
+, at body
+
+(defun notmuch-show-save-part (message-id nth  filename content-type)
+  (notmuch-with-temp-part-buffer message-id nth
+(let ((file (read-file-name
+"Filename to save as: "
+(or mailcap-download-directory "~/")
+nil nil
+filename)))
+  ;; Don't re-compress .gz & al.  Arguably we should make
+  ;; `file-name-handler-alist' nil, but that would chop
+  ;; ange-ftp, which is reasonable to use here.
+  (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion 
t
+
+(defun notmuch-show-view-part (message-id nth  filename content-type )
+  (notmuch-with-temp-part-buffer message-id nth
+;; set mm-inlined-types to nil to force an external viewer
+(let

[PATCH 3/3] emacs: Optionally hide some part headers.

Add a regexp, `notmuch-show-part-headers-hidden' and if the
content-type of a part matches, don't show the part header.
---
 emacs/notmuch-show.el |   41 +++--
 1 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 97e2a15..fa826f7 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -110,6 +110,12 @@ indentation."
   :group 'notmuch
   :type 'boolean)

+(defcustom notmuch-show-part-headers-hidden nil
+  "Headers for parts whose content-type matches this regexp will
+not be shown."
+  :group 'notmuch
+  :type 'regexp)
+
 (defmacro with-current-notmuch-show-message ( body)
   "Evaluate body with current buffer set to the text of current message"
   `(save-excursion
@@ -285,23 +291,30 @@ message at DEPTH in the current thread."
   'follow-link t
   'face 'message-mml)

+(defun notmuch-show-hidden-part-header (content-type)
+  "Return non-nil if a part header should be hidden for
+CONTENT-TYPE parts."
+  (and notmuch-show-part-headers-hidden
+   (string-match notmuch-show-part-headers-hidden content-type)))
+
 (defun notmuch-show-insert-part-header (nth content-type declared-type
 name comment
 button-parameters)
-  (apply #'insert-button
-(concat "[ "
-(if name (concat name ": ") "")
-declared-type
-(if (not (string-equal declared-type content-type))
-(concat " (as " content-type ")")
-  "")
-(or comment "")
-" ]")
-:type 'notmuch-show-part-button-type
-:notmuch-part nth
-:notmuch-filename name
-button-parameters)
-  (insert "\n"))
+  (unless (notmuch-show-hidden-part-header content-type)
+(apply #'insert-button
+  (concat "[ "
+  (if name (concat name ": ") "")
+  declared-type
+  (if (not (string-equal declared-type content-type))
+  (concat " (as " content-type ")")
+"")
+  (or comment "")
+  " ]")
+  :type 'notmuch-show-part-button-type
+  :notmuch-part nth
+  :notmuch-filename name
+  button-parameters)
+(insert "\n")))

 ;; Functions handling particular MIME parts.

-- 
1.7.8.3

[PATCH 2/3] emacs: Don't return the button from `notmuch-show-insert-part-header'.

Instead, allow the caller to specify some parameters for the
button. Rework `notmuch-show-insert-part-multipart/signed' and
`notmuch-show-insert-part-multipart/encrypted' accordingly, moving
most of the code into a common
`notmuch-show-insert-part-multipart/signed-or-encrypted' to reduce
duplication.
---

The buttons inserted for encrypted parts are slightly different now -
previously the logic was that if a part was encrypted it would have
the signature status inserted only if the encryption status was
specified. Now the signature status will be inserted even without
encryption status. My reading of the documentation says that this is
correct, but I'm no expert. Comments?

 emacs/notmuch-show.el |   88 +---
 1 files changed, 39 insertions(+), 49 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f62f8ac..97e2a15 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -285,22 +285,23 @@ message at DEPTH in the current thread."
   'follow-link t
   'face 'message-mml)

-(defun notmuch-show-insert-part-header (nth content-type declared-type 
 name comment)
-  (let ((button (insert-button
-(concat "[ "
-(if name (concat name ": ") "")
-declared-type
-(if (not (string-equal declared-type content-type))
-(concat " (as " content-type ")")
-  "")
-(or comment "")
-" ]")
-:type 'notmuch-show-part-button-type
-:notmuch-part nth
-:notmuch-filename name)))
-(insert "\n")
-;; return button
-button))
+(defun notmuch-show-insert-part-header (nth content-type declared-type
+name comment
+button-parameters)
+  (apply #'insert-button
+(concat "[ "
+(if name (concat name ": ") "")
+declared-type
+(if (not (string-equal declared-type content-type))
+(concat " (as " content-type ")")
+  "")
+(or comment "")
+" ]")
+:type 'notmuch-show-part-button-type
+:notmuch-part nth
+:notmuch-filename name
+button-parameters)
+  (insert "\n"))

 ;; Functions handling particular MIME parts.

@@ -458,42 +459,31 @@ current buffer, if possible."
   t)

 (defun notmuch-show-insert-part-multipart/signed (msg part content-type nth 
depth declared-type)
-  (let ((button (notmuch-show-insert-part-header nth declared-type 
content-type nil)))
-(button-put button 'face 'notmuch-crypto-part-header)
-;; add signature status button if sigstatus provided
-(if (plist-member part :sigstatus)
-   (let* ((from (notmuch-show-get-header :From msg))
-  (sigstatus (car (plist-get part :sigstatus
- (notmuch-crypto-insert-sigstatus-button sigstatus from))
-  ;; if we're not adding sigstatus, tell the user how they can get it
-  (button-put button 'help-echo "Set notmuch-crypto-process-mime to 
process cryptographic mime parts.")))
-
-  (let ((inner-parts (plist-get part :content))
-   (start (point)))
-;; Show all of the parts.
-(mapc (lambda (inner-part)
-   (notmuch-show-insert-bodypart msg inner-part depth))
- inner-parts)
-
-(when notmuch-show-indent-multipart
-  (indent-rigidly start (point) 1)))
-  t)
+  (notmuch-show-insert-part-multipart/signed-or-encrypted msg part 
content-type nth depth declared-type
+(plist-get part 
:sigstatus)
+nil))

 (defun notmuch-show-insert-part-multipart/encrypted (msg part content-type nth 
depth declared-type)
-  (let ((button (notmuch-show-insert-part-header nth declared-type 
content-type nil)))
-(button-put button 'face 'notmuch-crypto-part-header)
-;; add encryption status button if encstatus specified
-(if (plist-member part :encstatus)
-   (let ((encstatus (car (plist-get part :encstatus
- (notmuch-crypto-insert-encstatus-button encstatus)
- ;; add signature status button if sigstatus specified
- (if (plist-member part :sigstatus)
- (let* ((from (notmuch-show-get-header :From msg))
-(sigstatus (car (plist-get part :sigstatus
-   (notmuch-crypto-insert-sigstatus-button sigstatus from
-  ;; if we're not adding encstatus, tell the user how they can get it
-  (button-put button 'help-echo "Set notmuch-crypto-process-mime to 
process cryptographic mime parts.")))
+  (notmuch-show-insert-part-multipart/signed-or-encrypted msg part 
content-type nth depth declared-type
+(plist-get part 
:sigstatus)
+

[PATCH 1/3] emacs: Tidy `notmuch-show-insert-part-header'.

---
 emacs/notmuch-show.el |   26 --
 1 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 03c1f6b..f62f8ac 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -286,20 +286,18 @@ message at DEPTH in the current thread."
   'face 'message-mml)

 (defun notmuch-show-insert-part-header (nth content-type declared-type 
 name comment)
-  (let ((button))
-(setq button
- (insert-button
-  (concat "[ "
-  (if name (concat name ": ") "")
-  declared-type
-  (if (not (string-equal declared-type content-type))
-  (concat " (as " content-type ")")
-"")
-  (or comment "")
-  " ]")
-  :type 'notmuch-show-part-button-type
-  :notmuch-part nth
-  :notmuch-filename name))
+  (let ((button (insert-button
+(concat "[ "
+(if name (concat name ": ") "")
+declared-type
+(if (not (string-equal declared-type content-type))
+(concat " (as " content-type ")")
+  "")
+(or comment "")
+" ]")
+:type 'notmuch-show-part-button-type
+:notmuch-part nth
+:notmuch-filename name)))
 (insert "\n")
 ;; return button
 button))
-- 
1.7.8.3

[PATCH v4 1/1] Make buttons for attachments allow viewing as well as saving


On Thu, 19 Jan 2012 23:30:23 -0500, Austin Clements  wrote:
> One indentation nit and then this LGTM.
> 
> > +  (lexical-let ((message-id message-id)
> > +   (nth nth)
> > +   (filename filename)
> > +   (content-type content-type))
> > +  (flet ((mm-save-part ( args) (notmuch-show-save-part
> 
> This body of lexical-let should be indented like a normal let body.
> You might have to load cl to get this indentation rule.

Fixed. Patch to follow in reply.

Thanks

Mark

[PATCH v4 1/3] show: don't use hex literals in JSON output

On Fri, 20 Jan 2012 13:33:58 +0100, Thomas Jost  
wrote:

> The most common gmime error codes are 1 (expired signature), 2 (no
> public key), 4 (expired key) and 8 (revoked key). The other possible
> value is 16 (unsupported algorithm) but obviously it is much more rare.
> If this happens, the current code will add '"errors": 10' (hex for
> 16...). This is valid JSON (it looks like a decimal number) but it is
> incorrect (should be 16, not 10).

Maybe something like this for the commit message?

d

[PATCH v3 5/5] emacs: Use message-citation-line-format in reply

On Fri, 20 Jan 2012 00:53:39 -0500, Aaron Ecay  wrote:
> I?m personally of the opinion that notmuch should just say ?the mail
> composition facility is provided by message mode (here is the
> documentation on customizing it)?.

In general, +1.

> One possible step that might ease the transition pain could be for
> notmuch?s emacs interface to have a configuration file (similar to
> Wanderlust?s ~/.wl; I believe Gnus also uses a ~/.gnus).  The idea is
> that this file contains elisp code, and is loaded by notmuch the first
> time any notmuch-related commands are invoked by the user.

This is how my own configuration is stored (in ~/.notmuch.el).

> I?ll close with an example of a nice feature that message mode has
> (which I?ve been really wanting since the reply keybindings changed)
> that notmuch would get for free if it hooked into message mode better:
> the function message-widen-reply takes a reply-to-sender message and
> makes it reply-to-all.

That would require a bunch of work on our side to prepare the data that
message-mode uses, but would indeed be nice.
-- 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/20120120/fa81dd67/attachment.pgp>

[PATCH] emacs: Quote MML tags in replies

On Thu, 19 Jan 2012 13:43:09 -0500, Aaron Ecay  wrote:
> Emacs message-mode uses certain text strings to indicate how to attach
> files to outgoing mail.  If these are present in the text of an email,
> and a user is tricked into replying to the message, the user?s files
> could be exposed.
> ---

Can you include a NEWS patch against release with next version? We
should probably roll 0.11.1 with this fix.

d

[PATCH v4 1/3] show: don't use hex literals in JSON output

On Fri, 20 Jan 2012 10:39:23 +0100, Thomas Jost  
wrote:
> JSON does not support hex literals (0x..) so numbers must be formatted as %d
> instead of %x.
> ---
>  notmuch-show.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Probably I'm just being lazy here, but can you explain why this change
does not require a corresponding change on the emacs side?

d

[PATCH] emacs: Quote MML tags in replies

On Thu, 19 Jan 2012 13:43:09 -0500, Aaron Ecay  wrote:
> -  (message-goto-body))
> +  (message-goto-body)
> +  (mml-quote-region (point) (mark)))

Obviously good. It would be nice to have a comment about why it's `mark'
and not `point-max'. In fact, it would be good to have a comment
explaining why `mml-quote-region' is required.
-- 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/20120120/d71be9b8/attachment.pgp>

[PATCH] config: Better formatting for search section comment

On Wed, 18 Jan 2012 15:56:45 -0500, Austin Clements  wrote:
> Since "auto_exclude_tags" is long and its description is multi-line,
> start the description on the next line and indent it consistently.
> ---

pushed

d

[PATCH] emacs: fix tests wrt notmuch-hello invisible dot

2012-01-20 Thread Dmitry Kurochkin

On Thu, 19 Jan 2012 22:31:14 +0100, Pieter Praet  wrote:
> Not meant to be applied!
> 
> Should be merged into
>   id:"1326815734-20421-1-git-send-email-dmitry.kurochkin at gmail.com"
> 

Oops.  I managed to miss the failing tests.  I would send a new patch
version.

Regards,
  Dmitry

> ---
>  test/emacs.expected-output/notmuch-hello   |2 +-
>  .../notmuch-hello-no-saved-searches|2 +-
>  .../emacs.expected-output/notmuch-hello-with-empty |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/test/emacs.expected-output/notmuch-hello 
> b/test/emacs.expected-output/notmuch-hello
> index de57de2..196112e 100644
> --- a/test/emacs.expected-output/notmuch-hello
> +++ b/test/emacs.expected-output/notmuch-hello
> @@ -4,7 +4,7 @@ Saved searches: [edit]
>  
> 52 inbox   52 unread
>  
> -Search:  
> +Search: .
>  
>  [Show all tags]
>  
> diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches 
> b/test/emacs.expected-output/notmuch-hello-no-saved-searches
> index f1fc4d6..f4cfe49 100644
> --- a/test/emacs.expected-output/notmuch-hello-no-saved-searches
> +++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches
> @@ -1,6 +1,6 @@
> Welcome to notmuch. You have 52 messages.
>  
> -Search:  
> +Search: .
>  
>  [Show all tags]
>  
> diff --git a/test/emacs.expected-output/notmuch-hello-with-empty 
> b/test/emacs.expected-output/notmuch-hello-with-empty
> index dd8728b..a860a72 100644
> --- a/test/emacs.expected-output/notmuch-hello-with-empty
> +++ b/test/emacs.expected-output/notmuch-hello-with-empty
> @@ -4,7 +4,7 @@ Saved searches: [edit]
>  
> 52 inbox   52 unread   0 empty 
>  
> -Search:  
> +Search: .
>  
>  [Show all tags]
>  
> -- 
> 1.7.8.1
>

[PATCH] test: always report missing prereqs, independent of `--verbose' option

On Fri, 20 Jan 2012 01:24:02 +0100, Pieter Praet  wrote:
> [...]
> Most likely because "$test_subtest_missing_external_prereqs_" is only
> reset at the beginning of every test series, so if an Emacs-dependent
> subtest is skipped, all subsequent skipped subtests will report that
> dependency as well, even if they were skipped due to a missing vi :).
> [...]

That's not right at all.

"$test_subtest_missing_external_prereqs_" is reset at every invocation
of `test_begin_subtest', using `test_reset_state_'.

Apologies for the misinformation.

Peace

-- 
Pieter

[PATCH] test: always report missing prereqs, independent of `--verbose' option

On Wed, 18 Jan 2012 15:53:59 +0200, Tomi Ollila  wrote:
> On Wed, 18 Jan 2012 13:19:41 +0100, Pieter Praet  wrote:
> > When tests are skipped due to missing prereqs, those prereqs are only
> > displayed when running with the `--verbose' option.  This is essential
> > information when troubleshooting, so always send to stdout.
> > 
> > ---
> 
> Instead of this the test suite could be enchanged so that
> full log of the execution is stored somewhere and path
> to that file is displayed at the end of test. Generally,
> all output could stay available after tests exit so that
> those could be investigated furtner.
> 

Indeed.  AFAIK, this used to be possible using the `--tee' option,
but the files it produces appear to be deleted when the tests finish.

> (I tried to grep 'missing prerequisites' after running test
> but did not find the info. the file opened for >&3 has been
> deleted already?)
> 

Hmmm, odd.

Are you sure you were using my patch and/or the `--verbose' option?

Works here, using this highly sophisticated Emacs-hiding wizardry:

  #+begin_src sh
sudo mv /usr/bin/emacs /usr/bin/emacs.bak
make test | grep 'missing prerequisites'
sudo mv /usr/bin/emacs.bak /usr/bin/emacs
  #+end_src

(patent pending... ;)

> Now I just see huge amounts of missing prerequisites: emacs(1)
> in my output (I presume that doesn't happen due to my
> hack to "hide" emacs).
> 

When using my patch, you mean?

Most likely because "$test_subtest_missing_external_prereqs_" is only
reset at the beginning of every test series, so if an Emacs-dependent
subtest is skipped, all subsequent skipped subtests will report that
dependency as well, even if they were skipped due to a missing vi :).

> But well, I'm not against applying this patch -- just that
> the test system starts to get so rotten touching it gives
> shivers...
> 

I wouldn't say it's getting rotten, but yeah, "tread lightly" should
probably be mandatory advice to those aspiring to explore its bowels...

> Tomi
> 
> > 
> >  test/test-lib.sh |4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/test/test-lib.sh b/test/test-lib.sh
> > index d1fbc05..6560628 100644
> > --- a/test/test-lib.sh
> > +++ b/test/test-lib.sh
> > @@ -673,8 +673,8 @@ test_skip () {
> >  
> >  test_check_missing_external_prereqs_ () {
> > if test -n "$test_subtest_missing_external_prereqs_"; then
> > -   say_color skip >&3 "missing prerequisites:"
> > -   echo "$test_subtest_missing_external_prereqs_" >&3
> > +   say_color skip >&1 "missing prerequisites:"
> > +   echo "$test_subtest_missing_external_prereqs_" >&1
> > test_report_skip_ "$@"
> > else
> > false
> > -- 
> > 1.7.8.1


Peace

-- 
Pieter

[PATCH v3 2/2] Add compatibility with gmime 2.6

There are lots of API changes in gmime 2.6 crypto handling. By adding
preprocessor directives, it is however possible to add gmime 2.6 compatibility
while preserving compatibility with gmime 2.4 too.

This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".

This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is
currently broken (signature verification with signer key unavailable), most
likely because of a bug in gmime which will hopefully be fixed in a future
version.
---
 mime-node.c  |   60 --
 notmuch-client.h |   30 -
 notmuch-reply.c  |7 
 notmuch-show.c   |   95 ++
 show-message.c   |4 ++
 test/crypto  |2 +
 6 files changed, 192 insertions(+), 6 deletions(-)

diff --git a/mime-node.c b/mime-node.c
index d26bb44..ad19f5e 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -33,7 +33,11 @@ typedef struct mime_node_context {
 GMimeMessage *mime_message;

 /* Context provided by the caller. */
+#ifdef GMIME_ATLEAST_26
+GMimeCryptoContext *cryptoctx;
+#else
 GMimeCipherContext *cryptoctx;
+#endif
 notmuch_bool_t decrypt;
 } mime_node_context_t;

@@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)

 notmuch_status_t
 mime_node_open (const void *ctx, notmuch_message_t *message,
-   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
-   mime_node_t **root_out)
+#ifdef GMIME_ATLEAST_26
+   GMimeCryptoContext *cryptoctx,
+#else
+   GMimeCipherContext *cryptoctx,
+#endif
+   notmuch_bool_t decrypt, mime_node_t **root_out)
 {
 const char *filename = notmuch_message_get_filename (message);
 mime_node_context_t *mctx;
@@ -112,12 +120,21 @@ DONE:
 return status;
 }

+#ifdef GMIME_ATLEAST_26
+static int
+_signature_list_free (GMimeSignatureList **proxy)
+{
+g_object_unref (*proxy);
+return 0;
+}
+#else
 static int
 _signature_validity_free (GMimeSignatureValidity **proxy)
 {
 g_mime_signature_validity_free (*proxy);
 return 0;
 }
+#endif

 static mime_node_t *
 _mime_node_create (const mime_node_t *parent, GMimeObject *part)
@@ -165,11 +182,24 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
GMimeMultipartEncrypted *encrypteddata =
GMIME_MULTIPART_ENCRYPTED (part);
node->decrypt_attempted = TRUE;
+#ifdef GMIME_ATLEAST_26
+   GMimeDecryptResult *decrypt_result = NULL;
+   node->decrypted_child = g_mime_multipart_encrypted_decrypt
+   (encrypteddata, node->ctx->cryptoctx, _result, );
+#else
node->decrypted_child = g_mime_multipart_encrypted_decrypt
(encrypteddata, node->ctx->cryptoctx, );
+#endif
if (node->decrypted_child) {
node->decrypt_success = node->verify_attempted = TRUE;
+#ifdef GMIME_ATLEAST_26
+   /* This may be NULL if the part is not signed. */
+   node->sig_list = g_mime_decrypt_result_get_signatures 
(decrypt_result);
+   g_object_ref (node->sig_list);
+   g_object_unref (decrypt_result);
+#else
node->sig_validity = 
g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
+#endif
} else {
fprintf (stderr, "Failed to decrypt part: %s\n",
 (err ? err->message : "no error explanation given"));
@@ -182,6 +212,15 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
 "(must be exactly 2)\n",
 node->nchildren);
} else {
+#ifdef GMIME_ATLEAST_26
+   node->sig_list = g_mime_multipart_signed_verify
+   (GMIME_MULTIPART_SIGNED (part), node->ctx->cryptoctx, );
+   node->verify_attempted = TRUE;
+
+   if (!node->sig_list)
+   fprintf (stderr, "Failed to verify signed part: %s\n",
+(err ? err->message : "no error explanation given"));
+#else
/* For some reason the GMimeSignatureValidity returned
 * here is not a const (inconsistent with that
 * returned by
@@ -195,17 +234,30 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
node->verify_attempted = TRUE;
node->sig_validity = sig_validity;
if (sig_validity) {
-   GMimeSignatureValidity **proxy =
-   talloc (node, GMimeSignatureValidity *);
+   GMimeSignatureValidity **proxy = talloc (node, 
GMimeSignatureValidity *);
*proxy = sig_validity;
talloc_set_destructor (proxy, _signature_validity_free);
}
+#endif
}
 }

+#ifdef GMIME_ATLEAST_26
+/* sig_list may be created in both above cases, so we need to
+ * cleanly handle it

[PATCH v3 1/2] show: don't use hex literals in JSON output

JSON does not support hex literals (0x..) so numbers must be formatted as %d
instead of %x.
---
 notmuch-show.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index d14dac9..91f566c 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -641,7 +641,7 @@ format_part_sigstatus_json (const GMimeSignatureValidity* 
validity)
printf (", \"keyid\": %s", json_quote_str (ctx_quote, 
signer->keyid));
}
if (signer->errors != GMIME_SIGNER_ERROR_NONE) {
-   printf (", \"errors\": %x", signer->errors);
+   printf (", \"errors\": %d", signer->errors);
}

printf ("}");
-- 
1.7.8.4

[PATCH v3 0/2] gmime 2.6 compatibilty, 3rd iteration

Hi list,

Here's another update of the patches to add gmime 2.6 compatibilty
while still preserving compatibility with gmime 2.4.

Any comments or review will be much appreciated.

The changes compared to the previous version ([1] and [2]) are pretty
minor:
- space and indentation fixes
- correctly dereference the instance of GMimeDecryptResult allocated
  by g_mime_decrypt_result_get_signatures()
- remove a useless local variable
- rename the preprocessor constant GMIME_26 to GMIME_ATLEAST_26
- mark one crypto test as broken when using gmime 2.6 (because of a
  bug in gmime [3])

The first patch is really not specific to gmime so it could probably
be pushed right away.

Thanks to Austin Clements, Tomi Ollila and Adrian Perez for their
reviews of the previous patches!

Best regards,
Thomas

[1] id:"1326797453-9405-1-git-send-email-schnouki at schnouki.net"
[2] id:"1326797453-9405-2-git-send-email-schnouki at schnouki.net"
[3] https://bugzilla.gnome.org/show_bug.cgi?id=668085

Thomas Jost (2):
  show: don't use hex literals in JSON output
  Add compatibility with gmime 2.6

 mime-node.c  |   60 +++--
 notmuch-client.h |   30 +++-
 notmuch-reply.c  |7 
 notmuch-show.c   |   97 +-
 show-message.c   |4 ++
 test/crypto  |2 +
 6 files changed, 193 insertions(+), 7 deletions(-)

-- 
1.7.8.4

[PATCH] Automatically exclude tags in notmuch-show

On Thu, 19 Jan 2012 17:59:10 -0500, Austin Clements  wrote:
> LGTM, but should definitely come with a test.
> 

[...]

> Also, this won't commute with Pieter's patch
> (id:"1327000744-25463-2-git-send-email-pieter at praet.org"), so one or
> the other will have to get updated.
> 

No problem, I'll have to resubmit my entire series anyway,
so go right ahead.

> Quoth Mark Walters on Jan 19 at 10:03 pm:
> > Add the use of auto_exclude_tags in notmuch-show.c.  As with Austin's
> > patch (commit 42a907992823030f070fc395a174f779998ca6f5) it just adds
> > the excluded tags to the query so the excluded messages will still
> > appear in the emacs interface, but as a single header line rather than
> > as a matching message.
> > ---
> >  notmuch-show.c |8 
> >  1 files changed, 8 insertions(+), 0 deletions(-)
> > 
> > diff --git a/notmuch-show.c b/notmuch-show.c
> > index d14dac9..925dfd6 100644
> > --- a/notmuch-show.c
> > +++ b/notmuch-show.c
> > @@ -948,9 +948,12 @@ notmuch_show_command (void *ctx, unused (int argc), 
> > unused (char *argv[]))
> >  char *opt;
> >  const notmuch_show_format_t *format = _text;
> >  notmuch_show_params_t params;
> > +const char **auto_exclude_tags;
> > +size_t auto_exclude_tags_length;
> >  int mbox = 0;
> >  int format_specified = 0;
> >  int i;
> > +unsigned int j;
> 
> Hah.  The original patch series updated 'count' to use the new
> argument parsing solely so I could steal 'i' for the tag exclude code.
> 
> >  
> >  params.entire_thread = 0;
> >  params.raw = 0;
> > @@ -1040,6 +1043,11 @@ notmuch_show_command (void *ctx, unused (int argc), 
> > unused (char *argv[]))
> > return 1;
> >  }
> >  
> > +auto_exclude_tags = notmuch_config_get_auto_exclude_tags
> > +(config, _exclude_tags_length);
> > +for (j = 0; j < auto_exclude_tags_length; j++)
> > +notmuch_query_add_tag_exclude (query, auto_exclude_tags[j]);
> > +
> >  /* if part was requested and format was not specified, use format=raw 
> > */
> >  if (params.part >= 0 && !format_specified)
> > format = _raw;
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter

[PATCH v3 5/5] emacs: Use message-citation-line-format in reply

2012-01-20 Thread Aaron Ecay

On Thu, 19 Jan 2012 21:46:46 -0700, Adam Wolfe Gordon  
wrote:
> On Thu, Jan 19, 2012 at 11:45, Aaron Ecay  wrote:
> > Shouldn?t this just use message-insert-formatted-citation-line?
> 
> Yes, good idea.  I just tried this and it almost works.  The only
> issue is that the default message-mode-citation-line-format has a
> newline at the end, and this function inserts an *additional* newline,
> so we end up with a blank line before the beginning of the quoted
> text.  This is fixable by the user, of course, but it means the
> default out-of-the-box setup will create funny-looking replies, which
> is probably bad.  Thoughts?

(let ((message-citation-line-format
   (remove ?\n message-citation-line-format)))
  ...)

(Or, if you think someone might have a newline other than at the end of
the string, you could do something a little more complicated to remove
only a newline at the end.)

Or you could introduce a new defcustom
?notmuch-message-citation-line-format? (with newline-less default), and
let-bind m-l-c-f to that value.  But that is pretty ugly ? we don?t want
to have to ?wrap? every variable whose default we don?t like.

> I've also tried using message-cite-original to create the reply body,
> and it also almost works.  The issue, again, is one of defaults.  In
> addition to the blank line I mentioned above, the default
> message-citation-line-function inserts the "plain" citation line "Foo
>  writes:" instead of the formatted one.  This is a big
> change from the current notmuch default.
> 
> If everyone's OK with this and willing to customize it themselves,
> then I'm happy to go with this solution, but I'm pretty reluctant to
> change the default in such a significant way.

I?m personally of the opinion that notmuch should just say ?the mail
composition facility is provided by message mode (here is the
documentation on customizing it)?.  Message mode is 8,000 lines of
elisp.  We have the choice to:
- write our own message composition mode
- wrap (as explained above) the default message-mode variables we don?t
  like in notmuch-prefixed variants, with suitable let-bindings.
- use only the parts of message-mode that we like
- pass composition off to message mode

The first option just doesn?t make sense.  The second is also a little
nuts.  The third is what we are trying now, but it?s painful ? the
message mode code has its own structure and its own defaults, which
don?t always agree with notmuch?s.  I am in favor of the fourth ?
notmuch?s elisp code should pass data to message mode in the most low
level form it can, and let message mode do any extra work in the way
it already does.  And users should customize message composition via
message mode, not notmuch.  There?s a tradeoff to this approach ? by
controlling more within notmuch, we can have nicer defaults at the
expense of more brittle code and/or fewer user-visible customizations.

This is not in any way a criticism of your work (which is great) ?
you?re right that you need ?permission? to uproot the defaults, and I?m
advocating for it to be given.

One possible step that might ease the transition pain could be for
notmuch?s emacs interface to have a configuration file (similar to
Wanderlust?s ~/.wl; I believe Gnus also uses a ~/.gnus).  The idea is
that this file contains elisp code, and is loaded by notmuch the first
time any notmuch-related commands are invoked by the user.  If the file
does not exist, notmuch could create it with default content that sets
message-citation-function, message-citation-line-format,
message-yank-prefix (to get rid of the ugly default whereby message-mode
indents the original message by four spaces instead of inserting ?> ?),
etc.  If there is interest in this approach, I?d be happy to work on a
patch for it.

I?ve sort of stumped for this idea before
(id:"m239bgcd1d.fsf at gmail.com") and it didn?t exactly get rave reviews.
So I?ll shut up if it?s really not something people want to see.

I?ll close with an example of a nice feature that message mode has
(which I?ve been really wanting since the reply keybindings changed)
that notmuch would get for free if it hooked into message mode better:
the function message-widen-reply takes a reply-to-sender message and
makes it reply-to-all.

-- 
Aaron Ecay

[PATCH] Add pseudo-compatibility with gmime 2.6

On Tue, 17 Jan 2012 15:38:36 -0500, Austin Clements  wrote:
> Quoth Thomas Jost on Jan 17 at 11:48 am:
> > On Mon, 16 Jan 2012 22:47:14 -0500, Austin Clements  
> > wrote:
> > > Quoth Thomas Jost on Jan 17 at 12:56 am:
> > > > This is mostly based on id:"8762i8hrb9.fsf at bookbinder.fernseed.info".
> > > > 
> > > > This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, 
> > > > the
> > > > crypto tests all work fine (as expected). With gmime 2.6.4, one crypto 
> > > > test
> > > > fails (signature verification with signer key unavailable) but this 
> > > > will be hard
> > > > to fix since the new API does not report the reason why a signature 
> > > > verification
> > > > fails (other than the human-readable error message).
> > > 
> > > What is the result of this failing test?
> > 
> > The test looks like that:
> > 
> > FAIL   signature verification with signer key unavailable
> >--- crypto.4.expected   2012-01-16 23:05:06.765651183 +
> >+++ crypto.4.output 2012-01-16 23:05:06.765651183 +
> >@@ -12,9 +12,7 @@
> >  "Bcc": "",
> >  "Date": "01 Jan 2000 12:00:00 -"},
> >  "body": [{"id": 1,
> >- "sigstatus": [{"status": "error",
> >- "keyid": "6D92612D94E46381",
> >- "errors": 2}],
> >+ "sigstatus": [],
> >  "content-type": "multipart/signed",
> >  "content": [{"id": 2,
> >  "content-type": "text/plain",
> >Failed to verify signed part: gpg: keyblock resource 
> > `/home/schnouki/dev/notmuch/test/tmp.crypto/gnupg/pubring.gpg': file open 
> > error
> >gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
> >gpg: Signature made Mon Jan 16 23:05:06 2012 UTC using RSA key ID 
> > 94E46381
> >gpg: Can't check signature: public key not found
> > 
> > So basically if a signer public key is missing, we can't get the status
> > signature: empty "sigstatus" field in the JSON output, "Unknown
> > signature status" in Emacs.
> > 
> > IMHO this is a bug in gmime 2.6, and I think I know what causes it. I'll
> > file a bug in gmime and hopefully they'll find a cleaner way to fix it
> > than the one I came up with :)
> 
> Oh, okay.  That does seem like a bug in GMime.  Do you think it would
> be possible to mark this test as "broken" if notmuch is using GMime
> 2.6?  Off the top of my head, I can't think of an easy way to plumb
> that information through to the test suite.  I don't think we should
> push any patches that knowingly break a test, even if it's in just one
> configuration.

Here is how I did:

  (ldd notmuch | grep -q gmime-2.6) && test_subtest_known_broken

ldd notmuch will show "/path/to/libgmime-2.4.so.*" or
"libgmime-2.6.so.*" so we can easily check this in the test suite.
It's a little hacky but it seems to work. AFAIK ldd is a pretty standard
tool so it should be available (almost) everywhere. However if you have
a better idea I'll be glad to hear it.

> > > > +#ifdef GMIME_26
> > > > +if (node->verify_attempted && !node->sig_list)
> > > 
> > > Hmm.  This is correct for signed parts, but will incorrectly trigger
> > > for an encrypted part with no signatures.  For 2.6, I think this error
> > > checking may have to move into the branches of the if encrypted/signed
> > > since for encrypted parts you have to check if
> > > g_mime_multipart_encrypted_decrypt returned NULL.
> > 
> > That sound right. The weird part is that it did not cause anything to
> > fail in the test suite...
> 
> It would be worth adding a test with an encrypted but unsigned part.
> I don't know enough GPG myself to do that.

It looks like there's already one: "emacs delivery of encrypted message
with attachment" + following decryptions.

Regards,

-- 
Thomas/Schnouki
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120120/1544b0d5/attachment.pgp>

[PATCH v3] emacs: add invisible dot instead of space at the end of notmuch-hello search box

From: Dmitry Kurochkin 

This makes `show-trailing-whitespace' happy, i.e. it does not mark the
whole search box line as trailing spaces.

Since the dot is invisible, this change makes no visible difference
for `notmuch-hello'.

Edited-by: Pieter Praet  to fix the tests.
---
 emacs/notmuch-hello.el |9 ++---
 test/emacs.expected-output/notmuch-hello   |2 +-
 .../notmuch-hello-no-saved-searches|2 +-
 .../emacs.expected-output/notmuch-hello-with-empty |2 +-
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index bff95ac..55b7877 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -511,9 +511,12 @@ Complete list of currently available key bindings:
   (length "Search: ")))
   :action (lambda (widget  ignore)
 (notmuch-hello-search (widget-value widget
-   ;; add an invisible space to make `widget-end-of-line' ignore
-   ;; trailine spaces in the search widget field
-   (widget-insert " ")
+   ;; Add an invisible dot to make `widget-end-of-line' ignore
+   ;; trailing spaces in the search widget field.  A dot is used
+   ;; instead of a space to make `show-trailing-whitespace'
+   ;; happy, i.e. avoid it marking the whole line as trailing
+   ;; spaces.
+   (widget-insert ".")
(put-text-property (1- (point)) (point) 'invisible t)
(widget-insert "\n")

diff --git a/test/emacs.expected-output/notmuch-hello 
b/test/emacs.expected-output/notmuch-hello
index de57de2..196112e 100644
--- a/test/emacs.expected-output/notmuch-hello
+++ b/test/emacs.expected-output/notmuch-hello
@@ -4,7 +4,7 @@ Saved searches: [edit]

  52 inbox   52 unread

-Search:  
+Search: .

 [Show all tags]

diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches 
b/test/emacs.expected-output/notmuch-hello-no-saved-searches
index f1fc4d6..f4cfe49 100644
--- a/test/emacs.expected-output/notmuch-hello-no-saved-searches
+++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches
@@ -1,6 +1,6 @@
Welcome to notmuch. You have 52 messages.

-Search:  
+Search: .

 [Show all tags]

diff --git a/test/emacs.expected-output/notmuch-hello-with-empty 
b/test/emacs.expected-output/notmuch-hello-with-empty
index dd8728b..a860a72 100644
--- a/test/emacs.expected-output/notmuch-hello-with-empty
+++ b/test/emacs.expected-output/notmuch-hello-with-empty
@@ -4,7 +4,7 @@ Saved searches: [edit]

  52 inbox   52 unread   0 empty 

-Search:  
+Search: .

 [Show all tags]

-- 
1.7.8.1

[PATCH] emacs: fix tests wrt notmuch-hello invisible dot

On Fri, 20 Jan 2012 02:37:30 +0400, Dmitry Kurochkin  wrote:
> On Thu, 19 Jan 2012 22:31:14 +0100, Pieter Praet  wrote:
> > Not meant to be applied!
> > 
> > Should be merged into
> >   id:"1326815734-20421-1-git-send-email-dmitry.kurochkin at gmail.com"
> > 
> 
> Oops.  I managed to miss the failing tests.  I would send a new patch
> version.
> 

Sorry, yeah, that would probably have been a better idea.

Amended patch follows (let's hope `git send-email' does the right thing).


> Regards,
>   Dmitry
> 
> > ---
> >  test/emacs.expected-output/notmuch-hello   |2 +-
> >  .../notmuch-hello-no-saved-searches|2 +-
> >  .../emacs.expected-output/notmuch-hello-with-empty |2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/test/emacs.expected-output/notmuch-hello 
> > b/test/emacs.expected-output/notmuch-hello
> > index de57de2..196112e 100644
> > --- a/test/emacs.expected-output/notmuch-hello
> > +++ b/test/emacs.expected-output/notmuch-hello
> > @@ -4,7 +4,7 @@ Saved searches: [edit]
> >  
> >   52 inbox   52 unread
> >  
> > -Search:
> >   
> > +Search:
> >  .
> >  
> >  [Show all tags]
> >  
> > diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches 
> > b/test/emacs.expected-output/notmuch-hello-no-saved-searches
> > index f1fc4d6..f4cfe49 100644
> > --- a/test/emacs.expected-output/notmuch-hello-no-saved-searches
> > +++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches
> > @@ -1,6 +1,6 @@
> > Welcome to notmuch. You have 52 messages.
> >  
> > -Search:
> >   
> > +Search:
> >  .
> >  
> >  [Show all tags]
> >  
> > diff --git a/test/emacs.expected-output/notmuch-hello-with-empty 
> > b/test/emacs.expected-output/notmuch-hello-with-empty
> > index dd8728b..a860a72 100644
> > --- a/test/emacs.expected-output/notmuch-hello-with-empty
> > +++ b/test/emacs.expected-output/notmuch-hello-with-empty
> > @@ -4,7 +4,7 @@ Saved searches: [edit]
> >  
> >   52 inbox   52 unread   0 empty 
> >  
> > -Search:
> >   
> > +Search:
> >  .
> >  
> >  [Show all tags]
> >  
> > -- 
> > 1.7.8.1
> > 


Peace

-- 
Pieter

[PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6

On Wed, 18 Jan 2012 12:35:34 -0500, Austin Clements  wrote:
> Quoth Tomi Ollila on Jan 18 at 10:15 am:
> > On Tue, 17 Jan 2012 17:25:46 -0500, Austin Clements  
> > wrote:
> > > Quoth Thomas Jost on Jan 17 at 11:50 am:
> > > >  
> > > > +#ifdef GMIME_26
> > > > +/* sig_list may be created in both above cases, so we need to
> > > > + * cleanly handle it here. */
> > > > +if (node->sig_list) {
> > > > +   GMimeSignatureList **proxy =
> > > > +   talloc (node, GMimeSignatureList *);
> > > 
> > > This doesn't need to be split into two lines.
> > > 
> > > > +   *proxy = node->sig_list;
> > > > +   talloc_set_destructor (proxy, _signature_list_free);
> > > > +}
> > > > +#else
> > > >  if (node->verify_attempted && !node->sig_validity)
> > > > fprintf (stderr, "Failed to verify signed part: %s\n",
> > > >  (err ? err->message : "no error explanation given"));
> > > > +#endif
> > > 
> > > I'd rather see the above as a separate #ifdef GMIME_26 and #ifndef
> > > GMIME_26, since they aren't logical alternates of each other.
> > 
> > That reminds me that it should then be like GMIME_ATLEAST_26, so
> > that this might be useful when GMIME > 2.6 is available...
> 
> Hopefully before GMIME 2.8 comes out, we'll be able to remove all of
> the GMIME 2.4 compatibility.  But GMIME_ATLEAST_26 would be fine, too.

Heh, maybe things will change again in 2.8 and "ATLEAST_26" will become
"ONLY_26"... But changed to GMIME_ATLEAST_26 anyway, thanks for the
suggestion :)

-- 
Thomas/Schnouki
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120120/00362800/attachment.pgp>

[PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6

 signature_status_to_string (status)));
> > +
> > +   GMimeCertificate *certificate = g_mime_signature_get_certificate 
> > (signature);
> > +   if (status == GMIME_SIGNATURE_STATUS_GOOD) {
> > +   if (certificate)
> > +   printf (", \"fingerprint\": %s", json_quote_str (ctx_quote, 
> > g_mime_certificate_get_fingerprint (certificate)));
> > +   /* these dates are seconds since the epoch; should we
> > +* provide a more human-readable format string? */
> > +   time_t created = g_mime_signature_get_created (signature);
> > +   if (created != -1)
> > +   printf (", \"created\": %d", (int) created);
> > +   time_t expires = g_mime_signature_get_expires (signature);
> > +   if (expires > 0)
> > +   printf (", \"expires\": %d", (int) expires);
> > +   /* output user id only if validity is FULL or ULTIMATE. */
> > +   /* note that gmime is using the term "trust" here, which
> > +* is WRONG.  It's actually user id "validity". */
> > +   if (certificate) {
> > +   const char *name = g_mime_certificate_get_name (certificate);
> > +   GMimeCertificateTrust trust = g_mime_certificate_get_trust 
> > (certificate);
> > +   if (name && (trust == GMIME_CERTIFICATE_TRUST_FULLY || trust == 
> > GMIME_CERTIFICATE_TRUST_ULTIMATE))
> > +   printf (", \"userid\": %s", json_quote_str (ctx_quote, 
> > name));
> > +   }
> > +   } else if (certificate) {
> > +   const char *key_id = g_mime_certificate_get_key_id (certificate);
> > +   if (key_id)
> > +   printf (", \"keyid\": %s", json_quote_str (ctx_quote, key_id));
> > +   }
> > +
> > +   GMimeSignatureError errors = g_mime_signature_get_errors (signature);
> > +   if (errors != GMIME_SIGNATURE_ERROR_NONE) {
> > +   printf (", \"errors\": %d", errors);
> > +   }
> > +
> > +   printf ("}");
> > + }
> > +
> > +printf ("]");
> > +
> > +talloc_free (ctx_quote);
> > +}
> > +#else
> >  static void
> >  format_part_sigstatus_json (const GMimeSignatureValidity* validity)
> >  {
> > @@ -652,6 +739,7 @@ format_part_sigstatus_json (const 
> > GMimeSignatureValidity* validity)
> >  
> >  talloc_free (ctx_quote);
> >  }
> > +#endif
> >  
> >  static void
> >  format_part_content_json (GMimeObject *part)
> > @@ -990,13 +1078,20 @@ notmuch_show_command (void *ctx, unused (int argc), 
> > unused (char *argv[]))
> > } else if ((STRNCMP_LITERAL (argv[i], "--verify") == 0) ||
> >(STRNCMP_LITERAL (argv[i], "--decrypt") == 0)) {
> > if (params.cryptoctx == NULL) {
> > +#ifdef GMIME_26
> > +   /* TODO: GMimePasswordRequestFunc */
> > +   if (NULL == (params.cryptoctx = g_mime_gpg_context_new(NULL, 
> > "gpg")))
> > +#else
> > GMimeSession* session = g_object_new(g_mime_session_get_type(), 
> > NULL);
> > if (NULL == (params.cryptoctx = g_mime_gpg_context_new(session, 
> > "gpg")))
> > +#endif
> > fprintf (stderr, "Failed to construct gpg context.\n");
> > else
> > 
> > g_mime_gpg_context_set_always_trust((GMimeGpgContext*)params.cryptoctx, 
> > FALSE);
> > +#ifndef GMIME_26
> > g_object_unref (session);
> > session = NULL;
> > +#endif
> > }
> > if (STRNCMP_LITERAL (argv[i], "--decrypt") == 0)
> > params.decrypt = 1;
> > diff --git a/show-message.c b/show-message.c
> > index 8768889..65269fd 100644
> > --- a/show-message.c
> > +++ b/show-message.c
> > @@ -48,7 +48,11 @@ show_message_part (mime_node_t *node,
> > format->part_encstatus (node->decrypt_success);
> >  
> >  if (node->verify_attempted && format->part_sigstatus)
> > +#ifdef GMIME_26
> > +   format->part_sigstatus (node->sig_list);
> > +#else
> > format->part_sigstatus (node->sig_validity);
> > +#endif
> >  
> >  format->part_content (part);
> >  

-- 
Thomas/Schnouki
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120120/35372ddb/attachment.pgp>

[PATCH] emacs: Quote MML tags in replies

On Thu, 19 Jan 2012 17:56:16 -0500, Aaron Ecay  wrote:
> On Thu, 19 Jan 2012 17:48:42 -0500, Austin Clements  
> wrote:
> > Did you consider using point-max instead of mark?  IIRC, that mark was
> > very recently introduced which, perhaps irrationally, makes it seem
> > less future-proof to me.
> 
> Well, if the patch goes in and someone changes the code so that it no
> longer sets the mark (in the same way), they will be the one breaking
> stuff, and they?ll have to come up with the fix themself.  [...]

True that.


> [...] Using point-max
> would include the signature in the quoting as well.  It would probably be
> fairly odd to want to put an MML tag in one?s signature, but that doesn?t
> mean that we should break that usage.
> 

So, would I be right to assume MML tags in signatures are never
evaluated to begin with?  Otherwise, there would still be a security
hole, no?


> > 
> > >  
> > >  (defun notmuch-mua-forward-message ()
> > >(message-forward)
> > 
> > Speaking of future-proofing, it would be good to have a test.
> 
> It would.  ;)  I?ll work on one.
> 

Thanks!

These might save you some time:
  id:"1310313335-4159-1-git-send-email-pieter at praet.org"


> -- 
> Aaron Ecay
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter

[PATCH] emacs: Quote MML tags in replies

On Thu, 19 Jan 2012 17:52:23 -0500, Aaron Ecay  wrote:
> On Thu, 19 Jan 2012 17:46:31 -0500, Austin Clements  
> wrote:
> > > ### OT:
> > > For some reason, `mml-quote-region' explicitly re-quotes
> > > already quoted MML tags:
> > > 
> > >   "<#!*/?\\(multipart\\|part\\|external\\|mml\\)"
> > > 
> > > Why is that ?
> > 
> > Probably so the transformation is invertible, though as far as I can
> > tell there's no mml-unquote-region.
> 
> Sending the message (or doing M-x mml-preview) undoes the quoting.  So
> if the original message contains an already-quoted tag, constructing the
> reply double-quotes it, and sending the reply will produce the original
> single-quoted tag again.
> 

Thanks!

This list just keeps on giving;  Free education, I tell ya...


> -- 
> Aaron Ecay


Peace

-- 
Pieter

[PATCH] Automatically exclude tags in notmuch-show


Ok Having said this is trivial I have found a problem. What should
notmuch do if you do something like

notmuch show id:
and that message is marked with a deleted tag? To be consistent with the
other cases (where a deleted message is in a matched thread) we might
want to return the message with the not-matched flag set (eg in
JSON). But my patch doesn't, as it never even sees the thread since it
doesn't match.

Looking at notmuch-show.c I think we should not apply the exclude tags
to do_show_single, but usually should apply it to do_show. One solution
which is simple and is at least close to right would be to get do_show
to return the number of threads found. If this is zero then retry the
query without the excludes (possible setting the match_flag to zero on
each message since we know it does not match)

This is not a completely correct solution as if you ask notmuch-show to
show more than one thread it might  threads which only contain deleted
messages.

I can't see other good possibilities without slowing down the normal
path a lot (eg find all threads that match the original query and then
apply the argument above).

Any thoughts?

Incidentally, is there something strange at the end of notmuch-show.c: I
can't see how we could ever reach the last half dozen lines.

Best wishes

Mark

Re: [PATCH v3 2/2] Add compatibility with gmime 2.6

On Thu, 19 Jan 2012 23:10:44 -0500, Austin Clements amdra...@mit.edu wrote:
 Nearly there.  A few more small comments.

Thanks again :) Will post new version soon, including a new patch to
update NEWS and INSTALL.

 Quoth Thomas Jost on Jan 20 at  1:06 am:
  There are lots of API changes in gmime 2.6 crypto handling. By adding
  preprocessor directives, it is however possible to add gmime 2.6 
  compatibility
  while preserving compatibility with gmime 2.4 too.
  
  This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.
  
  This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
  crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test 
  is
  currently broken (signature verification with signer key unavailable), most
  likely because of a bug in gmime which will hopefully be fixed in a future
  version.
  ---
   mime-node.c  |   60 --
   notmuch-client.h |   30 -
   notmuch-reply.c  |7 
   notmuch-show.c   |   95 
  ++
   show-message.c   |4 ++
   test/crypto  |2 +
   6 files changed, 192 insertions(+), 6 deletions(-)
  
  diff --git a/mime-node.c b/mime-node.c
  index d26bb44..ad19f5e 100644
  --- a/mime-node.c
  +++ b/mime-node.c
  @@ -33,7 +33,11 @@ typedef struct mime_node_context {
   GMimeMessage *mime_message;
   
   /* Context provided by the caller. */
  +#ifdef GMIME_ATLEAST_26
  +GMimeCryptoContext *cryptoctx;
  +#else
   GMimeCipherContext *cryptoctx;
  +#endif
   notmuch_bool_t decrypt;
   } mime_node_context_t;
   
  @@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
   
   notmuch_status_t
   mime_node_open (const void *ctx, notmuch_message_t *message,
  -   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
  -   mime_node_t **root_out)
  +#ifdef GMIME_ATLEAST_26
  +   GMimeCryptoContext *cryptoctx,
  +#else
  +   GMimeCipherContext *cryptoctx,
  +#endif
  +   notmuch_bool_t decrypt, mime_node_t **root_out)
   {
   const char *filename = notmuch_message_get_filename (message);
   mime_node_context_t *mctx;
  @@ -112,12 +120,21 @@ DONE:
   return status;
   }
   
  +#ifdef GMIME_ATLEAST_26
  +static int
  +_signature_list_free (GMimeSignatureList **proxy)
  +{
  +g_object_unref (*proxy);
  +return 0;
  +}
  +#else
   static int
   _signature_validity_free (GMimeSignatureValidity **proxy)
   {
   g_mime_signature_validity_free (*proxy);
   return 0;
   }
  +#endif
   
   static mime_node_t *
   _mime_node_create (const mime_node_t *parent, GMimeObject *part)
  @@ -165,11 +182,24 @@ _mime_node_create (const mime_node_t *parent, 
  GMimeObject *part)
  GMimeMultipartEncrypted *encrypteddata =
  GMIME_MULTIPART_ENCRYPTED (part);
  node-decrypt_attempted = TRUE;
  +#ifdef GMIME_ATLEAST_26
  +   GMimeDecryptResult *decrypt_result = NULL;
  +   node-decrypted_child = g_mime_multipart_encrypted_decrypt
  +   (encrypteddata, node-ctx-cryptoctx, decrypt_result, err);
  +#else
  node-decrypted_child = g_mime_multipart_encrypted_decrypt
  (encrypteddata, node-ctx-cryptoctx, err);
  +#endif
  if (node-decrypted_child) {
  node-decrypt_success = node-verify_attempted = TRUE;
  +#ifdef GMIME_ATLEAST_26
  +   /* This may be NULL if the part is not signed. */
  +   node-sig_list = g_mime_decrypt_result_get_signatures 
  (decrypt_result);
  +   g_object_ref (node-sig_list);
 
 Apparently you can't g_object_ref NULL, so there should be a
 conditional around this.

Right, added. Thanks.

 (Does g_mime_decrypt_result_get_signatures *really* return NULL for an
 empty list? I feel like various tests should have failed in various
 versions of this patch if it did.)

Yes it does. I added some fprintf() in gmime (in gpg_decrypt() and
g_mime_decrypt_result_get_signatures()). Decryption tests (after emacs
delivery of encrypted message with attachment) clearly show that
g_mime_decrypt_result_get_signatures returns NULL when there's no
signatures in an encrypted part.

I guess the reason why tests did not fail is that
format_part_sigstatus_json just displays an empty JSON array if sig_list
is NULL. And that's also what's expected when an encrypted part has no
signature.

I had a quick look at the GObject code; apparently if you pass NULL to
g_object_ref (or anything that is not a GObject) it will just return
NULL. So that's why this one did not fail either.

 
  +   g_object_unref (decrypt_result);
  +#else
  node-sig_validity = 
  g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
  +#endif
  } else {
  fprintf (stderr, Failed to decrypt part: %s\n,
   (err ? err-message : no error explanation given));
  @@ -182,6 +212,15 @@ _mime_node_create (const

[PATCH v4 1/3] show: don't use hex literals in JSON output

JSON does not support hex literals (0x..) so numbers must be formatted as %d
instead of %x.
---
 notmuch-show.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index d14dac9..91f566c 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -641,7 +641,7 @@ format_part_sigstatus_json (const GMimeSignatureValidity* 
validity)
printf (, \keyid\: %s, json_quote_str (ctx_quote, 
signer-keyid));
}
if (signer-errors != GMIME_SIGNER_ERROR_NONE) {
-   printf (, \errors\: %x, signer-errors);
+   printf (, \errors\: %d, signer-errors);
}
 
printf (});
-- 
1.7.8.4

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v4 2/3] Add compatibility with gmime 2.6

There are lots of API changes in gmime 2.6 crypto handling. By adding
preprocessor directives, it is however possible to add gmime 2.6 compatibility
while preserving compatibility with gmime 2.4 too.

This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.

This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is
currently broken (signature verification with signer key unavailable), most
likely because of a bug in gmime which will hopefully be fixed in a future
version.
---
 mime-node.c  |   57 +++-
 notmuch-client.h |   30 -
 notmuch-reply.c  |7 
 notmuch-show.c   |   95 ++
 show-message.c   |4 ++
 test/crypto  |2 +
 6 files changed, 191 insertions(+), 4 deletions(-)

diff --git a/mime-node.c b/mime-node.c
index d26bb44..27077f7 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -33,7 +33,11 @@ typedef struct mime_node_context {
 GMimeMessage *mime_message;
 
 /* Context provided by the caller. */
+#ifdef GMIME_ATLEAST_26
+GMimeCryptoContext *cryptoctx;
+#else
 GMimeCipherContext *cryptoctx;
+#endif
 notmuch_bool_t decrypt;
 } mime_node_context_t;
 
@@ -57,8 +61,12 @@ _mime_node_context_free (mime_node_context_t *res)
 
 notmuch_status_t
 mime_node_open (const void *ctx, notmuch_message_t *message,
-   GMimeCipherContext *cryptoctx, notmuch_bool_t decrypt,
-   mime_node_t **root_out)
+#ifdef GMIME_ATLEAST_26
+   GMimeCryptoContext *cryptoctx,
+#else
+   GMimeCipherContext *cryptoctx,
+#endif
+   notmuch_bool_t decrypt, mime_node_t **root_out)
 {
 const char *filename = notmuch_message_get_filename (message);
 mime_node_context_t *mctx;
@@ -112,12 +120,21 @@ DONE:
 return status;
 }
 
+#ifdef GMIME_ATLEAST_26
+static int
+_signature_list_free (GMimeSignatureList **proxy)
+{
+g_object_unref (*proxy);
+return 0;
+}
+#else
 static int
 _signature_validity_free (GMimeSignatureValidity **proxy)
 {
 g_mime_signature_validity_free (*proxy);
 return 0;
 }
+#endif
 
 static mime_node_t *
 _mime_node_create (const mime_node_t *parent, GMimeObject *part)
@@ -165,11 +182,25 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
GMimeMultipartEncrypted *encrypteddata =
GMIME_MULTIPART_ENCRYPTED (part);
node-decrypt_attempted = TRUE;
+#ifdef GMIME_ATLEAST_26
+   GMimeDecryptResult *decrypt_result = NULL;
+   node-decrypted_child = g_mime_multipart_encrypted_decrypt
+   (encrypteddata, node-ctx-cryptoctx, decrypt_result, err);
+#else
node-decrypted_child = g_mime_multipart_encrypted_decrypt
(encrypteddata, node-ctx-cryptoctx, err);
+#endif
if (node-decrypted_child) {
node-decrypt_success = node-verify_attempted = TRUE;
+#ifdef GMIME_ATLEAST_26
+   /* This may be NULL if the part is not signed. */
+   node-sig_list = g_mime_decrypt_result_get_signatures 
(decrypt_result);
+   if (node-sig_list)
+   g_object_ref (node-sig_list);
+   g_object_unref (decrypt_result);
+#else
node-sig_validity = 
g_mime_multipart_encrypted_get_signature_validity (encrypteddata);
+#endif
} else {
fprintf (stderr, Failed to decrypt part: %s\n,
 (err ? err-message : no error explanation given));
@@ -182,6 +213,15 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
 (must be exactly 2)\n,
 node-nchildren);
} else {
+#ifdef GMIME_ATLEAST_26
+   node-sig_list = g_mime_multipart_signed_verify
+   (GMIME_MULTIPART_SIGNED (part), node-ctx-cryptoctx, err);
+   node-verify_attempted = TRUE;
+
+   if (!node-sig_list)
+   fprintf (stderr, Failed to verify signed part: %s\n,
+(err ? err-message : no error explanation given));
+#else
/* For some reason the GMimeSignatureValidity returned
 * here is not a const (inconsistent with that
 * returned by
@@ -200,12 +240,25 @@ _mime_node_create (const mime_node_t *parent, GMimeObject 
*part)
*proxy = sig_validity;
talloc_set_destructor (proxy, _signature_validity_free);
}
+#endif
}
 }
 
+#ifdef GMIME_ATLEAST_26
+/* sig_list may be created in both above cases, so we need to
+ * cleanly handle it here. */
+if (node-sig_list) {
+   GMimeSignatureList **proxy = talloc (node, GMimeSignatureList *);
+   *proxy = node-sig_list;
+   talloc_set_destructor (proxy, _signature_list_free);
+}
+#endif
+
+#ifndef GMIME_ATLEAST_26
 if (node-verify_attempted  !node-sig_validity)

[PATCH v4 3/3] Update NEWS and INSTALL about gmime 2.6

---
 INSTALL |   12 ++--
 NEWS|9 +
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/INSTALL b/INSTALL
index e51b397..bc98f1d 100644
--- a/INSTALL
+++ b/INSTALL
@@ -20,8 +20,8 @@ configure stage.
 
 Dependencies
 
-Notmuch depends on three libraries: Xapian, GMime 2.4, and Talloc
-which are each described below:
+Notmuch depends on three libraries: Xapian, GMime 2.4 or 2.6, and
+Talloc which are each described below:
 
Xapian
--
@@ -39,14 +39,14 @@ which are each described below:
reading mail while notmuch would wait for Xapian when removing
the inbox and unread tags from messages in a thread.
 
-   GMime 2.4
-   -
-   GMime 2.4 provides decoding of MIME email messages for Notmuch.
+   GMime 2.4 or 2.6
+   
+   GMime provides decoding of MIME email messages for Notmuch.
 
Without GMime, Notmuch would not be able to extract and index
the actual text from email message encoded as BASE64, etc.
 
-   GMime 2.4 is available from http://spruce.sourceforge.net/gmime/
+   GMime is available from http://spruce.sourceforge.net/gmime/
 
Talloc
--
diff --git a/NEWS b/NEWS
index 6afa912..e78472c 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,15 @@ New functions
   notmuch_query_add_tag_exclude supports the new tag exclusion
   feature.
 
+Build fixes
+---
+
+Compatibility with GMime 2.6
+
+  It is now possible to build notmuch against both GMime 2.4 and 2.6.
+  However they may be some issues in PGP signature verification
+  because of a bug in current versions of GMime 2.6.
+
 Notmuch 0.11 (2012-01-13)
 =
 
-- 
1.7.8.4

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v4 1/1] Make buttons for attachments allow viewing as well as saving


On Thu, 19 Jan 2012 23:30:23 -0500, Austin Clements amdra...@mit.edu wrote:
 One indentation nit and then this LGTM.
 
  +  (lexical-let ((message-id message-id)
  +   (nth nth)
  +   (filename filename)
  +   (content-type content-type))
  +  (flet ((mm-save-part (rest args) (notmuch-show-save-part
 
 This body of lexical-let should be indented like a normal let body.
 You might have to load cl to get this indentation rule.

Fixed. Patch to follow in reply.

Thanks

Mark
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v5] Make buttons for attachments allow viewing as well as saving

Define a keymap for attachment buttons to allow multiple actions.
Define 3 possible actions:
save attachment: exactly as currently,
view attachment: uses mailcap entry,
view attachment with user chosen program

Keymap on a button is: s for save, v for view and o for view with
other program. Default (i.e. enter or mouse button) is save but this
is configurable in notmuch customize.

One implementation detail: the view attachment function forces all
attachments to be displayed using mailcap even if emacs could
display them itself. Thus, for example, text/html appears in a browser
and text/plain asks whether to save (on a standard debian setup)
---
 emacs/notmuch-show.el |  116 ++--
 1 files changed, 92 insertions(+), 24 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index fc13462..6229432 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -112,6 +112,16 @@ indentation.
   :type 'boolean
   :group 'notmuch-show)
 
+(defcustom notmuch-show-part-button-default-action 'notmuch-show-save-part
+  Default part header button action (on ENTER or mouse click).
+  :group 'notmuch-show
+  :type '(choice (const :tag Save part
+   notmuch-show-save-part)
+(const :tag View part
+   notmuch-show-view-part)
+(const :tag View interactively
+   notmuch-show-interactively-view-part)))
+
 (defmacro with-current-notmuch-show-message (rest body)
   Evaluate body with current buffer set to the text of current message
   `(save-excursion
@@ -283,10 +293,21 @@ message at DEPTH in the current thread.
(run-hooks 'notmuch-show-markup-headers-hook)
 
 (define-button-type 'notmuch-show-part-button-type
-  'action 'notmuch-show-part-button-action
+  'action 'notmuch-show-part-button-default
+  'keymap 'notmuch-show-part-button-map
   'follow-link t
   'face 'message-mml)
 
+(defvar notmuch-show-part-button-map
+  (let ((map (make-sparse-keymap)))
+(set-keymap-parent map button-map)
+(define-key map s 'notmuch-show-part-button-save)
+(define-key map v 'notmuch-show-part-button-view)
+(define-key map o 'notmuch-show-part-button-interactively-view)
+map)
+  Submap for button commands)
+(fset 'notmuch-show-part-button-map notmuch-show-part-button-map)
+
 (defun notmuch-show-insert-part-header (nth content-type declared-type 
optional name comment)
   (let ((button))
 (setq button
@@ -301,29 +322,58 @@ message at DEPTH in the current thread.
])
   :type 'notmuch-show-part-button-type
   :notmuch-part nth
-  :notmuch-filename name))
+  :notmuch-filename name
+  :notmuch-content-type content-type))
 (insert \n)
 ;; return button
 button))
 
 ;; Functions handling particular MIME parts.
 
-(defun notmuch-show-save-part (message-id nth optional filename)
-  (let ((process-crypto notmuch-show-process-crypto))
-(with-temp-buffer
-  (setq notmuch-show-process-crypto process-crypto)
-  ;; Always acquires the part via `notmuch part', even if it is
-  ;; available in the JSON output.
-  (insert (notmuch-show-get-bodypart-internal message-id nth))
-  (let ((file (read-file-name
-  Filename to save as: 
-  (or mailcap-download-directory ~/)
-  nil nil
-  filename)))
-   ;; Don't re-compress .gz  al.  Arguably we should make
-   ;; `file-name-handler-alist' nil, but that would chop
-   ;; ange-ftp, which is reasonable to use here.
-   (mm-write-region (point-min) (point-max) file nil nil nil 
'no-conversion t)
+(defmacro notmuch-with-temp-part-buffer (message-id nth rest body)
+  (declare (indent 2))
+  (let ((process-crypto (make-symbol process-crypto)))
+`(let ((,process-crypto notmuch-show-process-crypto))
+   (with-temp-buffer
+(setq notmuch-show-process-crypto ,process-crypto)
+;; Always acquires the part via `notmuch part', even if it is
+;; available in the JSON output.
+(insert (notmuch-show-get-bodypart-internal ,message-id ,nth))
+,@body
+
+(defun notmuch-show-save-part (message-id nth optional filename content-type)
+  (notmuch-with-temp-part-buffer message-id nth
+(let ((file (read-file-name
+Filename to save as: 
+(or mailcap-download-directory ~/)
+nil nil
+filename)))
+  ;; Don't re-compress .gz  al.  Arguably we should make
+  ;; `file-name-handler-alist' nil, but that would chop
+  ;; ange-ftp, which is reasonable to use here.
+  (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion 
t
+
+(defun notmuch-show-view-part (message-id nth optional filename content-type )
+  (notmuch-with-temp-part-buffer message-id nth
+;; set mm-inlined-types to nil to force an external viewer
+(let

Re: [PATCH v3 5/5] emacs: Use message-citation-line-format in reply

On Fri, 20 Jan 2012 00:53:39 -0500, Aaron Ecay e...@sas.upenn.edu wrote:
 I’m personally of the opinion that notmuch should just say “the mail
 composition facility is provided by message mode (here is the
 documentation on customizing it)”.

In general, +1.

 One possible step that might ease the transition pain could be for
 notmuch’s emacs interface to have a configuration file (similar to
 Wanderlust’s ~/.wl; I believe Gnus also uses a ~/.gnus).  The idea is
 that this file contains elisp code, and is loaded by notmuch the first
 time any notmuch-related commands are invoked by the user.

This is how my own configuration is stored (in ~/.notmuch.el).

 I’ll close with an example of a nice feature that message mode has
 (which I’ve been really wanting since the reply keybindings changed)
 that notmuch would get for free if it hooked into message mode better:
 the function message-widen-reply takes a reply-to-sender message and
 makes it reply-to-all.

That would require a bunch of work on our side to prepare the data that
message-mode uses, but would indeed be nice.


pgpVqNNOSanBQ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 3/3] emacs: Optionally hide some part headers.

Add a regexp, `notmuch-show-part-headers-hidden' and if the
content-type of a part matches, don't show the part header.
---
 emacs/notmuch-show.el |   41 +++--
 1 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 97e2a15..fa826f7 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -110,6 +110,12 @@ indentation.
   :group 'notmuch
   :type 'boolean)
 
+(defcustom notmuch-show-part-headers-hidden nil
+  Headers for parts whose content-type matches this regexp will
+not be shown.
+  :group 'notmuch
+  :type 'regexp)
+
 (defmacro with-current-notmuch-show-message (rest body)
   Evaluate body with current buffer set to the text of current message
   `(save-excursion
@@ -285,23 +291,30 @@ message at DEPTH in the current thread.
   'follow-link t
   'face 'message-mml)
 
+(defun notmuch-show-hidden-part-header (content-type)
+  Return non-nil if a part header should be hidden for
+CONTENT-TYPE parts.
+  (and notmuch-show-part-headers-hidden
+   (string-match notmuch-show-part-headers-hidden content-type)))
+
 (defun notmuch-show-insert-part-header (nth content-type declared-type
optional name comment
rest button-parameters)
-  (apply #'insert-button
-(concat [ 
-(if name (concat name : ) )
-declared-type
-(if (not (string-equal declared-type content-type))
-(concat  (as  content-type ))
-  )
-(or comment )
- ])
-:type 'notmuch-show-part-button-type
-:notmuch-part nth
-:notmuch-filename name
-button-parameters)
-  (insert \n))
+  (unless (notmuch-show-hidden-part-header content-type)
+(apply #'insert-button
+  (concat [ 
+  (if name (concat name : ) )
+  declared-type
+  (if (not (string-equal declared-type content-type))
+  (concat  (as  content-type ))
+)
+  (or comment )
+   ])
+  :type 'notmuch-show-part-button-type
+  :notmuch-part nth
+  :notmuch-filename name
+  button-parameters)
+(insert \n)))
 
 ;; Functions handling particular MIME parts.
 
-- 
1.7.8.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Quote MML tags in replies

On Thu, 19 Jan 2012 13:43:09 -0500, Aaron Ecay aarone...@gmail.com wrote:
 -  (message-goto-body))
 +  (message-goto-body)
 +  (mml-quote-region (point) (mark)))

Obviously good. It would be nice to have a comment about why it's `mark'
and not `point-max'. In fact, it would be good to have a comment
explaining why `mml-quote-region' is required.


pgpfUJ3Z51F5j.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 1/3] emacs: Tidy `notmuch-show-insert-part-header'.

---
 emacs/notmuch-show.el |   26 --
 1 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 03c1f6b..f62f8ac 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -286,20 +286,18 @@ message at DEPTH in the current thread.
   'face 'message-mml)
 
 (defun notmuch-show-insert-part-header (nth content-type declared-type 
optional name comment)
-  (let ((button))
-(setq button
- (insert-button
-  (concat [ 
-  (if name (concat name : ) )
-  declared-type
-  (if (not (string-equal declared-type content-type))
-  (concat  (as  content-type ))
-)
-  (or comment )
-   ])
-  :type 'notmuch-show-part-button-type
-  :notmuch-part nth
-  :notmuch-filename name))
+  (let ((button (insert-button
+(concat [ 
+(if name (concat name : ) )
+declared-type
+(if (not (string-equal declared-type content-type))
+(concat  (as  content-type ))
+  )
+(or comment )
+ ])
+:type 'notmuch-show-part-button-type
+:notmuch-part nth
+:notmuch-filename name)))
 (insert \n)
 ;; return button
 button))
-- 
1.7.8.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/3] emacs: Don't return the button from `notmuch-show-insert-part-header'.

Instead, allow the caller to specify some parameters for the
button. Rework `notmuch-show-insert-part-multipart/signed' and
`notmuch-show-insert-part-multipart/encrypted' accordingly, moving
most of the code into a common
`notmuch-show-insert-part-multipart/signed-or-encrypted' to reduce
duplication.
---

The buttons inserted for encrypted parts are slightly different now -
previously the logic was that if a part was encrypted it would have
the signature status inserted only if the encryption status was
specified. Now the signature status will be inserted even without
encryption status. My reading of the documentation says that this is
correct, but I'm no expert. Comments?

 emacs/notmuch-show.el |   88 +---
 1 files changed, 39 insertions(+), 49 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f62f8ac..97e2a15 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -285,22 +285,23 @@ message at DEPTH in the current thread.
   'follow-link t
   'face 'message-mml)
 
-(defun notmuch-show-insert-part-header (nth content-type declared-type 
optional name comment)
-  (let ((button (insert-button
-(concat [ 
-(if name (concat name : ) )
-declared-type
-(if (not (string-equal declared-type content-type))
-(concat  (as  content-type ))
-  )
-(or comment )
- ])
-:type 'notmuch-show-part-button-type
-:notmuch-part nth
-:notmuch-filename name)))
-(insert \n)
-;; return button
-button))
+(defun notmuch-show-insert-part-header (nth content-type declared-type
+   optional name comment
+   rest button-parameters)
+  (apply #'insert-button
+(concat [ 
+(if name (concat name : ) )
+declared-type
+(if (not (string-equal declared-type content-type))
+(concat  (as  content-type ))
+  )
+(or comment )
+ ])
+:type 'notmuch-show-part-button-type
+:notmuch-part nth
+:notmuch-filename name
+button-parameters)
+  (insert \n))
 
 ;; Functions handling particular MIME parts.
 
@@ -458,42 +459,31 @@ current buffer, if possible.
   t)
 
 (defun notmuch-show-insert-part-multipart/signed (msg part content-type nth 
depth declared-type)
-  (let ((button (notmuch-show-insert-part-header nth declared-type 
content-type nil)))
-(button-put button 'face 'notmuch-crypto-part-header)
-;; add signature status button if sigstatus provided
-(if (plist-member part :sigstatus)
-   (let* ((from (notmuch-show-get-header :From msg))
-  (sigstatus (car (plist-get part :sigstatus
- (notmuch-crypto-insert-sigstatus-button sigstatus from))
-  ;; if we're not adding sigstatus, tell the user how they can get it
-  (button-put button 'help-echo Set notmuch-crypto-process-mime to 
process cryptographic mime parts.)))
-
-  (let ((inner-parts (plist-get part :content))
-   (start (point)))
-;; Show all of the parts.
-(mapc (lambda (inner-part)
-   (notmuch-show-insert-bodypart msg inner-part depth))
- inner-parts)
-
-(when notmuch-show-indent-multipart
-  (indent-rigidly start (point) 1)))
-  t)
+  (notmuch-show-insert-part-multipart/signed-or-encrypted msg part 
content-type nth depth declared-type
+(plist-get part 
:sigstatus)
+nil))
 
 (defun notmuch-show-insert-part-multipart/encrypted (msg part content-type nth 
depth declared-type)
-  (let ((button (notmuch-show-insert-part-header nth declared-type 
content-type nil)))
-(button-put button 'face 'notmuch-crypto-part-header)
-;; add encryption status button if encstatus specified
-(if (plist-member part :encstatus)
-   (let ((encstatus (car (plist-get part :encstatus
- (notmuch-crypto-insert-encstatus-button encstatus)
- ;; add signature status button if sigstatus specified
- (if (plist-member part :sigstatus)
- (let* ((from (notmuch-show-get-header :From msg))
-(sigstatus (car (plist-get part :sigstatus
-   (notmuch-crypto-insert-sigstatus-button sigstatus from
-  ;; if we're not adding encstatus, tell the user how they can get it
-  (button-put button 'help-echo Set notmuch-crypto-process-mime to 
process cryptographic mime parts.)))
+  (notmuch-show-insert-part-multipart/signed-or-encrypted msg part 
content-type nth depth declared-type
+(plist-get part 
:sigstatus)
+

Re: [afew] announcing afew, an universal tagging solution with some fancy features

2012-01-20 Thread Patrick Totzke

Quoting Justus Winter (2011-12-21 08:53:23)
Hey Pazz,

Quoting Patrick Totzke (2011-12-19 19:17:12)
Also, should i not get some output when calling afew with -vv ?

Yes you should ;). Here's an example run on my box:
Alright, I do get logging output with upstream master thanks.

FYI: I found the problem with afew not finding new mails on my box.
I had the following in my ~/.notmuch-config:


#   tagsA list (separated by ';') of the tags that will be
#   added to all messages incorporated by notmuch new.
#
[new]
tags=new;

I suspect you don't split the config value and thus afew ended up with a false 
tag new;.
its just cosmetics but nevertheless..

Thanks for afew! I translated my static filter rules and am very much enjoying 
the automagic list-id tags :)
/p

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Updated remote script

On Thu, 19 Jan 2012 15:31:02 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:
 Hi Tomi,
 
 On Thu, 19 Jan 2012 19:50:38 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
  Quick comments: /tmp/notmuch_dtach.socket is dangerous (and the _ssh).
  
  either
  make directory /tmp/notmuch_`id -u`
  and chmod it to 0700
  and make sure you own it and it has right permissions.
  or
  make directory for these sockets in $HOME and chmod that to 700
  or
  just drop the socket in $HOME/.ssh (which should already be
  protected)
 
 Thanks very much for that. I made some quick changes, based on your
 first suggestion above. I'm pretty sure the checks are not in the most
 optimal order, but it seemed worth getting the changes up.

Indeed!

 As always, of course, anyone is more than welcome to change and improve
 the version up there. I was mainly changing it just to get my last
 error-ridden version out of circulation.

I'll probably play with that in (far ;) future...

 
 Thanks again,
 Jesse

Thanks, good script!

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] config: Better formatting for search section comment

On Wed, 18 Jan 2012 15:56:45 -0500, Austin Clements amdra...@mit.edu wrote:
 Since auto_exclude_tags is long and its description is multi-line,
 start the description on the next line and indent it consistently.
 ---

pushed

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3] emacs: add invisible dot instead of space at the end of notmuch-hello search box

On Fri, 20 Jan 2012 00:52:14 +0100, Pieter Praet pie...@praet.org wrote:
 From: Dmitry Kurochkin dmitry.kuroch...@gmail.com
 
 This makes `show-trailing-whitespace' happy, i.e. it does not mark the
 whole search box line as trailing spaces.
 
 Since the dot is invisible, this change makes no visible difference
 for `notmuch-hello'.
 
 Edited-by: Pieter Praet pie...@praet.org to fix the tests.
 ---

+1

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [afew] announcing afew, an universal tagging solution with some fancy features

2012-01-20 Thread Justus Winter

Quoting Patrick Totzke (2012-01-20 11:40:41)
Quoting Justus Winter (2011-12-21 08:53:23)
Hey Pazz,

Quoting Patrick Totzke (2011-12-19 19:17:12)
Also, should i not get some output when calling afew with -vv ?

Yes you should ;). Here's an example run on my box:
Alright, I do get logging output with upstream master thanks.

FYI: I found the problem with afew not finding new mails on my box.
I had the following in my ~/.notmuch-config:


#   tagsA list (separated by ';') of the tags that will be
#   added to all messages incorporated by notmuch new.
#
[new]
tags=new;

I suspect you don't split the config value and thus afew ended up with a false 
tag new;.
its just cosmetics but nevertheless..

Hm, actually it does exactly that:

def get_notmuch_new_tags():
return notmuch_settings.get('new', 'tags').split(';')

Could you post the relevant log messages?

Thanks for afew! I translated my static filter rules and am very much enjoying 
the automagic list-id tags :)
/p

Cool :)

Cheers,
Justus
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v4 1/3] show: don't use hex literals in JSON output

On Fri, 20 Jan 2012 10:39:23 +0100, Thomas Jost schno...@schnouki.net wrote:
 JSON does not support hex literals (0x..) so numbers must be formatted as %d
 instead of %x.
 ---
  notmuch-show.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
Probably I'm just being lazy here, but can you explain why this change
does not require a corresponding change on the emacs side?

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Quote MML tags in replies

On Thu, 19 Jan 2012 13:43:09 -0500, Aaron Ecay aarone...@gmail.com wrote:
 Emacs message-mode uses certain text strings to indicate how to attach
 files to outgoing mail.  If these are present in the text of an email,
 and a user is tricked into replying to the message, the user’s files
 could be exposed.
 ---

Can you include a NEWS patch against release with next version? We
should probably roll 0.11.1 with this fix.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v4 1/3] show: don't use hex literals in JSON output

On Fri, 20 Jan 2012 07:55:03 -0400, David Bremner da...@tethera.net wrote:
 On Fri, 20 Jan 2012 10:39:23 +0100, Thomas Jost schno...@schnouki.net wrote:
  JSON does not support hex literals (0x..) so numbers must be formatted as %d
  instead of %x.
  ---
   notmuch-show.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  
 Probably I'm just being lazy here, but can you explain why this change
 does not require a corresponding change on the emacs side?

Because Emacs already does the right thing. JSON numbers are supposed to
be decimal only (see http://json.org/: digits are 0-9 only), but the
current code could result in displaying a hexadecimal number instead
(c instead of 12). This would then trigger an error in Emacs, or in
any other correct JSON parser.

However we are quite lucky: because of the possible values of the gmime
error codes, such an error cannot happen.

The most common gmime error codes are 1 (expired signature), 2 (no
public key), 4 (expired key) and 8 (revoked key). The other possible
value is 16 (unsupported algorithm) but obviously it is much more rare.
If this happens, the current code will add 'errors: 10' (hex for
16...). This is valid JSON (it looks like a decimal number) but it is
incorrect (should be 16, not 10).

With this patch, notmuch will correctly display 'errors: 16' if such a
case happens.

(By the way, this issue was spotted by Austin Clements in
id:20120117034714.gg16...@mit.edu, so he deserves the credits :))

Regards,

-- 
Thomas/Schnouki


pgpaN5CBNzUcv.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v4 1/3] show: don't use hex literals in JSON output

On Fri, 20 Jan 2012 13:33:58 +0100, Thomas Jost schno...@schnouki.net wrote:

 The most common gmime error codes are 1 (expired signature), 2 (no
 public key), 4 (expired key) and 8 (revoked key). The other possible
 value is 16 (unsupported algorithm) but obviously it is much more rare.
 If this happens, the current code will add 'errors: 10' (hex for
 16...). This is valid JSON (it looks like a decimal number) but it is
 incorrect (should be 16, not 10).

Maybe something like this for the commit message?

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Add pseudo-compatibility with gmime 2.6

On Fri, 20 Jan 2012 00:52:47 +0100, Thomas Jost schno...@schnouki.net wrote:
 
 Here is how I did:
 
   (ldd notmuch | grep -q gmime-2.6)  test_subtest_known_broken
 
 ldd notmuch will show /path/to/libgmime-2.4.so.* or
 libgmime-2.6.so.* so we can easily check this in the test suite.
 It's a little hacky but it seems to work. AFAIK ldd is a pretty standard
 tool so it should be available (almost) everywhere. However if you have
 a better idea I'll be glad to hear it.

The hack is good in a sense that if that check fails in any case
the test_subtest_known_broken is not executed and we get FAIL instead of
BROKEN.
The subshell is unneeded:

ldd notmuch | grep -q gmime-2.6  test_subtest_known_broken

does the trick (potentially less forks)... ok now I have to test ;)

haha:
 $ rm xfoo.* xbar.*
 
 $ strace -ff -o xfoo sh -c '(ldd /bin/ls | grep -q libc)  echo foo'
 foo
 $ ls xfoo.*
 xfoo.14277  xfoo.14279  xfoo.14281  xfoo.14283  xfoo.14285
 xfoo.14278  xfoo.14280  xfoo.14282  xfoo.14284

 $ strace -ff -o xbar sh -c 'ldd /bin/ls | grep -q libc  echo foo'
 foo
 $ ls xbar.*
 xbar.14292  xbar.14294  xbar.14296  xbar.14298
 xbar.14293  xbar.14295  xbar.14297  xbar.14299


Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 2/3] show: Use consistent header ordering in the text format

On Wed, 18 Jan 2012 15:28:26 -0500, Austin Clements amdra...@mit.edu wrote:
 Previously, top-level message headers were printed as Subject, From,
 To, Date, while embedded message headers were printed From, To,
 Subject, Date.  This makes both cases use the former order and updates
 the tests accordingly.
 
 Strangely, the raw format also uses this function, so this also fixes
 the two raw format tests affected by this change.
 ---

LGTM (this patch).

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 1/2] show: Handle read and write errors

On Thu, 19 Jan 2012 17:29:18 -0500, Austin Clements amdra...@mit.edu wrote:
 For showing a message in raw format, rather than silently succeeding
 when a read or a write fails (or, probably, looping if a read fails),
 try to print an error message and exit with a non-zero status.
 
 This silences one of the buildbot warnings about unused resuls.  While
 my libc lacks the declarations that trigger these warnings, this can
 be tested by adding the following to notmuch.h:
 
 __attribute__((warn_unused_result))
 size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);
 ---

+1

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 2/2] Silence buildbot warnings about unused results

On Thu, 19 Jan 2012 17:29:19 -0500, Austin Clements amdra...@mit.edu wrote:
 This ignores the results of the two writes in sigint handlers even
 harder than before.
 
 While my libc lacks the declarations that trigger these warnings, this
 can be tested by adding the following to notmuch.h:
 
 __attribute__((warn_unused_result))
 ssize_t write(int fd, const void *buf, size_t count);
 ---

+1

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Make the part content available to `mm-inlinable-p'.

On Thu, 19 Jan 2012 09:34:07 +, David Edmondson d...@dme.org wrote:
 The `mm-inlinable-p' function works better if it has access to the
 data of the relevant part, so load that content before calling it.
 
 Don't load the content for parts that the user has indicated no desire
 to inline.
 
 This fixes the display of attached image/jpeg parts, for example.
 ---

LGTM.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v4 2/3] Add compatibility with gmime 2.6

LGTM!

Quoth Thomas Jost on Jan 20 at 10:39 am:
 There are lots of API changes in gmime 2.6 crypto handling. By adding
 preprocessor directives, it is however possible to add gmime 2.6 compatibility
 while preserving compatibility with gmime 2.4 too.
 
 This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.
 
 This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
 crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is
 currently broken (signature verification with signer key unavailable), most
 likely because of a bug in gmime which will hopefully be fixed in a future
 version.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v4 3/3] Update NEWS and INSTALL about gmime 2.6

Quoth Thomas Jost on Jan 20 at 10:39 am:
 ---
  INSTALL |   12 ++--
  NEWS|9 +
  2 files changed, 15 insertions(+), 6 deletions(-)
 
 diff --git a/INSTALL b/INSTALL
 index e51b397..bc98f1d 100644
 --- a/INSTALL
 +++ b/INSTALL
 @@ -20,8 +20,8 @@ configure stage.
  
  Dependencies
  
 -Notmuch depends on three libraries: Xapian, GMime 2.4, and Talloc
 -which are each described below:
 +Notmuch depends on three libraries: Xapian, GMime 2.4 or 2.6, and
 +Talloc which are each described below:
  
   Xapian
   --
 @@ -39,14 +39,14 @@ which are each described below:
   reading mail while notmuch would wait for Xapian when removing
   the inbox and unread tags from messages in a thread.
  
 - GMime 2.4
 - -
 - GMime 2.4 provides decoding of MIME email messages for Notmuch.
 + GMime 2.4 or 2.6
 + 
 + GMime provides decoding of MIME email messages for Notmuch.
  
   Without GMime, Notmuch would not be able to extract and index
   the actual text from email message encoded as BASE64, etc.
  
 - GMime 2.4 is available from http://spruce.sourceforge.net/gmime/
 + GMime is available from http://spruce.sourceforge.net/gmime/
  
   Talloc
   --
 diff --git a/NEWS b/NEWS
 index 6afa912..e78472c 100644
 --- a/NEWS
 +++ b/NEWS
 @@ -36,6 +36,15 @@ New functions
notmuch_query_add_tag_exclude supports the new tag exclusion
feature.
  
 +Build fixes
 +---
 +
 +Compatibility with GMime 2.6
 +
 +  It is now possible to build notmuch against both GMime 2.4 and 2.6.
 +  However they may be some issues in PGP signature verification

Typo and comma: However, there.  It would be good to describe the
bug, lest people hold off on upgrading because they think it's
something more dire.  Maybe

However, a bug in current GMime 2.6 causes notmuch not to report
signatures where the signer key is unavailable (GNOME bug 668085).

 +  because of a bug in current versions of GMime 2.6.
 +
  Notmuch 0.11 (2012-01-13)
  =
  
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

tach.el: an attachment interface for message mode.

Dear All,

I sent this to the list a couple of years back, but now that things are
moving again, and there are new eyes on the list, I thought I'd send it
again. I believe I'm the only person to use this (and might well
continue to be so) but I've been using it for a couple of years without
any problems, and it has made using message mode a lot more
convenient. As far as I know, this doesn't intersect with the recent
security problems pointed out in mml-mode, but I could be wrong.

My issue was this: the handling of (outgoing) attachments in
message-mode left a lot to be desired. MML's markup can be confusing,
and can easily be edited by mistake.

Thus: tach.el. Tach is a minor mode that adds mutt-like attachment
handling to message mode. It's not notmuch specific, but I wrote it to
use with notmuch, and I thought it might be of use to some on the
list.

You can find tach.el attached to this email.

To use tach, put tach.el in your load-path, and add the following to
your .emacs:

(require 'tach)
(add-hook 'message-mode-hook 'tach-minor-mode)

Now when you type C-c C-a in message-mode, you should get a new window
with an attachment list. In that window, you can add and delete
attachments using `+' and `-', and scroll through them using the arrow
keys or the emacs direction commands.

tach.el will convert the attachments into MML markup as a last
step before sending. Hopefully you should never have to deal with it by
hand.

Some details: tach actually makes a numerical list at the bottom of the
message itself, separated by a custom separator. The message is narrowed
to above this separator, and the attachment window is an indirect buffer
narrowed to the region below the separator. The separator is erased when
the messages are translated to mml markup at the end.

This has remained at its earliest stages, and the usual disclaimers
apply. It certainly needs more a lot more commenting and
documentation. But I thought it might be useful, or at least fun to play
around with. And it might fill a niche for some users, as notmuch's
popularity continues to grow.

Best,
Jesse




tach.el
Description: application/emacs-lisp
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Automatically exclude tags in notmuch-show

Quoth Mark Walters on Jan 20 at 12:10 am:
 
 Ok Having said this is trivial I have found a problem. What should
 notmuch do if you do something like
 
 notmuch show id:some-id
 and that message is marked with a deleted tag? To be consistent with the
 other cases (where a deleted message is in a matched thread) we might
 want to return the message with the not-matched flag set (eg in
 JSON). But my patch doesn't, as it never even sees the thread since it
 doesn't match.
 
 Looking at notmuch-show.c I think we should not apply the exclude tags
 to do_show_single, but usually should apply it to do_show. One solution
 which is simple and is at least close to right would be to get do_show
 to return the number of threads found. If this is zero then retry the
 query without the excludes (possible setting the match_flag to zero on
 each message since we know it does not match)
 
 This is not a completely correct solution as if you ask notmuch-show to
 show more than one thread it might  threads which only contain deleted
 messages.
 
 I can't see other good possibilities without slowing down the normal
 path a lot (eg find all threads that match the original query and then
 apply the argument above).
 
 Any thoughts?

Oh dear.

Well, here's one idea.  Instead of doing a single thread query in
show, do a thread query without the exclusions and then a message
query with the exclusions.  Output all of the messages from the first
query, but use the results of the second query to determine which
messages are matched.  The same could be accomplished in the library
somewhat more efficiently, but it's not obvious to me what the API
would be.

 Incidentally, is there something strange at the end of notmuch-show.c: I
 can't see how we could ever reach the last half dozen lines.

Yes, I've wondered about that before, too.  I think none of those
technically matter since they're all cleaning up resources that the OS
is about to clean up for us.  It would be a problem if the database
was open in write mode because Xapian's write lock hangs around for a
split second after the process terminates if you don't close the
database yourself, but in read mode it doesn't take any locks.  Not
that this excuses the code.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: tach.el: an attachment interface for message mode.

2012-01-20 Thread Aaron Ecay

Ha!  As I was recently looking at the MML stuff, I spent some time
googling around looking for this – I knew I had seen a “mutt-like”
attachment interface for emacs mail writing, but I couldn’t seem to come
across it.  I will definitely get it set up and play with it.  I don’t
have cause to attach files to email very often, but I’ll let you know
how it works out.

Thanks a lot,

-- 
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 5/5] emacs: Use message-citation-line-format in reply

2012-01-20 Thread Adam Wolfe Gordon

Erk, forgot to reply-all.  Aaron might get this twice.

On Thu, Jan 19, 2012 at 22:53, Aaron Ecay e...@sas.upenn.edu wrote:
 (let ((message-citation-line-format
   (remove ?\n message-citation-line-format)))
  ...)

 (Or, if you think someone might have a newline other than at the end of
 the string, you could do something a little more complicated to remove
 only a newline at the end.)

I did something like this initially, to make the test pass, but my
thought is that some people might intend for that newline to be there
and we shouldn't be removing it.  Perhaps I'm being overly sensitive
to people with odd setups ;-).

 Or you could introduce a new defcustom
 ‘notmuch-message-citation-line-format’ (with newline-less default), and
 let-bind m-l-c-f to that value.  But that is pretty ugly – we don’t want
 to have to “wrap” every variable whose default we don’t like.

Agreed, not a good solution.

 I’m personally of the opinion that notmuch should just say “the mail
 composition facility is provided by message mode (here is the
 documentation on customizing it)”.  Message mode is 8,000 lines of
 elisp.  We have the choice to:
 - write our own message composition mode
 - wrap (as explained above) the default message-mode variables we don’t
  like in notmuch-prefixed variants, with suitable let-bindings.
 - use only the parts of message-mode that we like
 - pass composition off to message mode

 The first option just doesn’t make sense.  The second is also a little
 nuts.  The third is what we are trying now, but it’s painful – the
 message mode code has its own structure and its own defaults, which
 don’t always agree with notmuch’s.  I am in favor of the fourth –
 notmuch’s elisp code should pass data to message mode in the most low
 level form it can, and let message mode do any extra work in the way
 it already does.  And users should customize message composition via
 message mode, not notmuch.  There’s a tradeoff to this approach – by
 controlling more within notmuch, we can have nicer defaults at the
 expense of more brittle code and/or fewer user-visible customizations.

 This is not in any way a criticism of your work (which is great) –
 you’re right that you need “permission” to uproot the defaults, and I’m
 advocating for it to be given.

I think we're on the same page here - I definitely prefer to have
notmuch-mua use existing emacs functionality wherever it makes sense.
The only question in my mind is how ugly we're willing to let the
defaults be in order to leverage existing stuff.

 One possible step that might ease the transition pain could be for
 notmuch’s emacs interface to have a configuration file (similar to
 Wanderlust’s ~/.wl; I believe Gnus also uses a ~/.gnus).  The idea is
 that this file contains elisp code, and is loaded by notmuch the first
 time any notmuch-related commands are invoked by the user.  If the file
 does not exist, notmuch could create it with default content that sets
 message-citation-function, message-citation-line-format,
 message-yank-prefix (to get rid of the ugly default whereby message-mode
 indents the original message by four spaces instead of inserting “ ”),
 etc.  If there is interest in this approach, I’d be happy to work on a
 patch for it.

This would be a good way to get around the ugly defaults problem, and
it would also be an easy way for people to share their notmuch/emacs
setups.  I already have my setup in a file separate from my normal
emacs config, and I run `emacs -q -l ~/.emacs-notmuch -f notmuch` so
it doesn't load my normal, programming-oriented setup.

One additional issue I noticed this morning with using
message-cite-original: it doesn't wrap/fill the quoted message.  I'm
guessing there's a way to make message-cite-original do this, but I
haven't figured it out.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Improving notmuch query documentation [was: Re: Partial words on notmuch search?]

2012-01-20 Thread Mark Anderson

On Tue, 17 Jan 2012 16:29:23 -0600, Austin Clements amdra...@mit.edu wrote:
 Quoth Andrei Popescu on Jan 18 at 12:14 am:
  On Lu, 16 ian 12, 21:34:31, Austin Clements wrote:
   Quoth Andrei Popescu on Jan 16 at 10:21 pm:
Where can I read more about this? (except the source :)
   
   Most of this is in the Xapian query syntax document you found.  Really
   we ought to beef-up Notmuch's query syntax documentation.
  
  If I get around to write something myself where do you suggest I should 
  start, the wiki or the manpage?
 
 Probably expanding man/man7/notmuch-search-terms.7 would be the way to
 go.

I would appreciate it if the limitations of id: search were explained
there too.  I have some rules that I would love to make based on pattern
matching the message-id of the message, because I have a tool that
generates scads of email and I want to be able to delete a lot of it.

I think that id: is only matchable as an entire string, and a
confirmation of that would be nice to see.

For those who cringe when hearing the mention of _deletion_ of emails,
do you have a suggestion for how many copies of bugs in the bug database
I should store in my mail repository?  Note that IT only gives me a
couple gigabytes of home directory storage, and I don't have an SSD
Linux laptop, so the index does eventually slow down.

In other words, there are plenty of emails I love to forget ever having
received. :)


-Mark

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Make the part content available to `mm-inlinable-p'.

On Thu, 19 Jan 2012 09:34:07 +, David Edmondson d...@dme.org wrote:
 The `mm-inlinable-p' function works better if it has access to the
 data of the relevant part, so load that content before calling it.
 
 Don't load the content for parts that the user has indicated no desire
 to inline.

So I'm a little confused here.  Is there some variable I need to set to
get inlinable stuff to display inline?  If so, I can't figure out what
it is.  I don't see anything relevant in notmuch config, and I'm not
finding anything in mm- either, although I'm not quite sure what I'm
looking for.

Currently I'm not getting any images displayed inline.  I used to get
some, but not all, but at the moment I'm just getting a little white box
with no image in it.  After applying this patch, I'm not getting any
attempt to inline images at all.  But I'm assuming there is some
variable I need to set that I haven't...

jamie.


pgpzzqqwvp03x.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2] emacs: Make the part content available to the mm-inline* checks.

On Wed, 18 Jan 2012 14:35:01 -0500, Austin Clements amdra...@mit.edu wrote:
 Shouldn't we only be doing this for parts with inline (or not
 attachment) content-disposition?  That's cheap to check.  Or do we
 actually want things like image attachments to get inlined, despite
 their disposition?

This is a good question, actually.  Should we just always ignore the
disposition, and inline stuff if it's inlinable?  Should this be
configurable?

The whole disposition thing is actually pretty confused in general, I
think.  I'm not sure if people realize this but parts that are
disposition attachment are not indexed by notmuch, even if they're
imminently indexable.  This seems wrong to me, as I would like to have
as much of the message indexed as possible, regardless of disposition.
I'm not sure what the original motivation was there.

I point this out because there's a kind of schizophrenia related to
disposition handling in general, and it might be worthwhile to clarify
how we expect them to be handled, both in terms of indexing and display.

jamie.


pgpYObkkl210l.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 2/3] emacs: Don't return the button from `notmuch-show-insert-part-header'.

On Fri, 20 Jan 2012 09:43:31 +, David Edmondson d...@dme.org wrote:
 The buttons inserted for encrypted parts are slightly different now -
 previously the logic was that if a part was encrypted it would have
 the signature status inserted only if the encryption status was
 specified. Now the signature status will be inserted even without
 encryption status. My reading of the documentation says that this is
 correct, but I'm no expert. Comments?

I need some more time to review this patch, but I don't think this is
correct.  The signature status of encrypted messages (or even if the
message was signed at all) comes from the decryption process.  They're
not independent.  If the decryption fails it's unknown if there was a
signature or not.

I need to look closer at this, though.  Hopefully this weekend.

jamie.


pgpAC4WS1w9Db.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [afew] announcing afew, an universal tagging solution with some fancy features

2012-01-20 Thread Kazuo Teramoto

On Fri, Jan 20, 2012 at 12:26:05PM +0100, Justus Winter wrote:
 Quoting Patrick Totzke (2012-01-20 11:40:41)
 I suspect you don't split the config value and thus afew ended up
 with a false tag new;. its just cosmetics but nevertheless..
 
 Hm, actually it does exactly that:
 
 def get_notmuch_new_tags():
 return notmuch_settings.get('new', 'tags').split(';')

The problem, I think, is caused by how python split the string
~~
 'new;'.split(';')
['new', '']
~~

So afew pass a query with 'tag:' and it don't match any message. What
about putting a strip(';') before the split()?


pgpdJQDyJqqeH.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] lib: Save filenames for files detected as not an email file in the database.

Later runs of notmuch new won't scan these files again and won't
print warnings.

Various programs (Dovecot, in my case) store indexes and caches and
such in the maildir.  Without this, notmuch persistently complains
about such files.
---
Every time I run notmuch new I get a slew of these warnings.  It was
starting to get on my nerves, so I implemented the solution suggested
by the TODO file.

 devel/TODO  |9 +++--
 lib/database.cc |   41 +
 test/new|   23 +++
 3 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/devel/TODO b/devel/TODO
index 4dda6f4..b64a26e 100644
--- a/devel/TODO
+++ b/devel/TODO
@@ -260,12 +260,9 @@ existing messages at the next database upgrade).
 Add support for the user to specify custom headers to be indexed (and
 re-index these for existing messages at the next database upgrade).
 
-Save filenames for files detected as not an email file in the
-database. This would allow for two things: 1. Optimizing notmuch new
-to not have to look at these files again (since they are potentially
-large so the detection could be potentially slow). 2. A notmuch
-search syntax could be added to allow the user to find these files,
-(and perhaps delete them or move them away as appropriate).
+Add a notmuch search syntax to allow uses to find files recorded as
+non-emails in the database (and perhaps delete them or move them away
+as appropriate).
 
 Fix filesystem/notmuch-new race condition by not updating database
 mtime for a directory if it is the same as the current mtime.
diff --git a/lib/database.cc b/lib/database.cc
index 8103bd9..fd1ec6e 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1618,6 +1618,43 @@ _notmuch_database_link_message (notmuch_database_t 
*notmuch,
 return NOTMUCH_STATUS_SUCCESS;
 }
 
+static notmuch_status_t
+_notmuch_database_add_nonemail (notmuch_database_t *notmuch,
+   const char *filename)
+{
+notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
+void *local = talloc_new (notmuch);
+char *term, *direntry;
+Xapian::docid id;
+
+if (notmuch-mode == NOTMUCH_DATABASE_MODE_READ_ONLY)
+   INTERNAL_ERROR (Failure to ensure database is writable);
+
+Xapian::WritableDatabase *db =
+   static_cast Xapian::WritableDatabase * (notmuch-xapian_db);
+
+/* Create a document to record the non-email */
+Xapian::Document nonemail;
+term = talloc_asprintf (local, %s%s, _find_prefix (type), nonemail);
+nonemail.add_term (term, 0);
+
+status = _notmuch_database_filename_to_direntry (local, notmuch,
+filename, direntry);
+if (status)
+   goto DONE;
+term = talloc_asprintf (local, %s%s, _find_prefix (file-direntry),
+   direntry);
+nonemail.add_term (term, 0);
+
+/* Add it to the database */
+id = _notmuch_database_generate_doc_id (notmuch);
+db-replace_document (id, nonemail);
+
+  DONE:
+talloc_free (local);
+return status;
+}
+
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *notmuch,
  const char *filename,
@@ -1673,6 +1710,10 @@ notmuch_database_add_message (notmuch_database_t 
*notmuch,
(subject == NULL || *subject == '\0') 
(to == NULL || *to == '\0'))
{
+   /* The file is not an email.  Record it so we don't
+* reconsider this file in the future, which prevents
+* potentially expensive scans and annoying warnings. */
+   _notmuch_database_add_nonemail (notmuch, filename);
ret = NOTMUCH_STATUS_FILE_NOT_EMAIL;
goto DONE;
}
diff --git a/test/new b/test/new
index 49f390d..346d453 100755
--- a/test/new
+++ b/test/new
@@ -153,4 +153,27 @@ rm -rf ${MAIL_DIR}/two
 output=$(NOTMUCH_NEW)
 test_expect_equal $output No new mail. Removed 3 messages.
 
+
+test_begin_subtest Skips non-email
+PRE_COUNT=$(notmuch search '*' | wc -l)
+echo I am not an email  ${MAIL_DIR}/nonemail
+output=$(NOTMUCH_NEW 21 | sed -n '/^Note:/p;$p' | sed 's/\(file:\) .*/\1 
XXX/')
+test_expect_equal $output Note: Ignoring non-mail file: XXX
+No new mail.
+
+test_begin_subtest Non-email files are not indexed
+POST_COUNT=$(notmuch search '*' | wc -l)
+test_expect_equal $PRE_COUNT $POST_COUNT
+
+test_begin_subtest Ignores non-email on second pass
+touch ${MAIL_DIR}
+output=$(NOTMUCH_NEW 21 | sed -n '/^Note:/p;$p' | sed 's/\(file:\) .*/\1 
XXX/')
+test_expect_equal $output No new mail.
+
+test_begin_subtest Detects deletion of non-email
+rm ${MAIL_DIR}/nonemail
+output=$(NOTMUCH_NEW)
+test_expect_equal $output No new mail. Removed 1 message.
+
+
 test_done
-- 
1.7.7.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 5/5] emacs: Use message-citation-line-format in reply

On Fri, 20 Jan 2012 10:22:09 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca 
wrote:
 Erk, forgot to reply-all.  Aaron might get this twice.

Pick this:  notmuch@notmuchmail.org  (and add to to/cc) next time you forgot
to press 'R' (that's what I do :)
 
 On Thu, Jan 19, 2012 at 22:53, Aaron Ecay e...@sas.upenn.edu wrote:
 
  One possible step that might ease the transition pain could be for
  notmuch’s emacs interface to have a configuration file (similar to
  Wanderlust’s ~/.wl; I believe Gnus also uses a ~/.gnus).  The idea is
  that this file contains elisp code, and is loaded by notmuch the first
  time any notmuch-related commands are invoked by the user.  If the file
  does not exist, notmuch could create it with default content that sets
  message-citation-function, message-citation-line-format,
  message-yank-prefix (to get rid of the ugly default whereby message-mode
  indents the original message by four spaces instead of inserting “ ”),
  etc.  If there is interest in this approach, I’d be happy to work on a
  patch for it.

Yes, that would be good -- then there is default file everyone can be
directed to...

 This would be a good way to get around the ugly defaults problem, and
 it would also be an easy way for people to share their notmuch/emacs
 setups.  I already have my setup in a file separate from my normal
 emacs config, and I run `emacs -q -l ~/.emacs-notmuch -f notmuch` so
 it doesn't load my normal, programming-oriented setup.

I used to do just that -- but then I cannot enter M-x notmuch in my
emacs for sending email from that particular emacs. Now I have something 
like:

(autoload 'notmuch ~/local/my-notmuch Notmuchmail t)

Where first lines add load path for notmuch, then (require 'notmuch)
and then stars loading configuration...

The question, in case that configuration file is added, where is it 
located: ~/.notmuch (to add yet another file there), or into
.notmuch/ directory or XDG -like .config/notmuch/ (config.el ?)

See: id:e1rdkcw-0007o7...@thinkbox.jade-hamburg.de

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: tach.el: an attachment interface for message mode.

2012-01-20 Thread Xavier Maillard

On Fri, 20 Jan 2012 12:04:49 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:

[ ... ]

 Thus: tach.el. Tach is a minor mode that adds mutt-like attachment
 handling to message mode. It's not notmuch specific, but I wrote it to
 use with notmuch, and I thought it might be of use to some on the
 list.

I like it.

 Now when you type C-c C-a in message-mode, you should get a new window
 with an attachment list. In that window, you can add and delete
 attachments using `+' and `-', and scroll through them using the arrow
 keys or the emacs direction commands.

Simple but at first it is not easy to understand what to do with that
window. Also, there is no way to toggle the window visibility. But for a
first shot, it is a good shot :D
 
I tried it by adding tach.el to myself. When sending the message, I have
been asked whether I'd like to update copyright date and change licence
to GPL3, huh ? Is this something specific to how tach.el works ?

/Xavier

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v4 2/3] Add compatibility with gmime 2.6

On Fri, 20 Jan 2012 10:39:24 +0100, Thomas Jost schno...@schnouki.net wrote:
 There are lots of API changes in gmime 2.6 crypto handling. By adding
 preprocessor directives, it is however possible to add gmime 2.6 compatibility
 while preserving compatibility with gmime 2.4 too.
 
 This is mostly based on id:8762i8hrb9@bookbinder.fernseed.info.
 
 This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
 crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is
 currently broken (signature verification with signer key unavailable), most
 likely because of a bug in gmime which will hopefully be fixed in a future
 version.
 ---

+1

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: tach.el: an attachment interface for message mode.