Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Jameson Graef Rollins]

On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre ra...@free.fr wrote:
 I like to use the space (and sometimes the backspace key) to read
 threads back and forth, but sometimes I might read stuff to quickly and
 archive a thread without wanting it. It is then complex to find it back
 (especially if the thread contained a single message and I hit space
 before actually reading the message, so I can't find it again).
 
 As a workaround, I have changed the space key function
 notmuch-show-advance-and-archive to not archive the thread if we are
 at the end of the thread, but to just do nothing. Thus I have to
 expicitely archive the thread when I have finished reading it, which I
 find much safer.

I completely agree with your discomfort with the current function bound
to space.  I don't like it at all, and I similarly rebound space to be a
much more sensible function:

(defun notmuch-show-advance ()
  Advance through messages in a thread.
  (interactive)
  (let ((end-of-this-message (notmuch-show-message-bottom)))
(cond
 ;; Ideally we would test `end-of-this-message' against the result
 ;; of `window-end', but that doesn't account for the fact that
 ;; the end of the message might be hidden, so we have to actually
 ;; go to the end, walk back over invisible text and then see if
 ;; point is visible.
 ((save-excursion
(goto-char (- end-of-this-message 1))
(notmuch-show-move-past-invisible-backward)
( (point) (window-end)))
  ;; The bottom of this message is not visible - scroll.
  (scroll-up nil))
 ((not (= end-of-this-message (point-max)))
  ;; This is not the last message - move to the next visible one.
  (notmuch-show-next-open-message))
 )))

Notice I also made it so that this does not exit the current thread
view.

jamie.


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

[SCM] notmuch - thread-based email index, search and tagging. annotated tag, 0.6, created. 0.6

[Jameson Graef Rollins]

On Fri,  1 Jul 2011 13:13:27 -0700 (PDT), notmuch-commits-sender at 
notmuchmail.org (David Bremner) wrote:
> The annotated tag, 0.6 has been created
> at  6eae40d57f12bb44d1b375a1d37454974f6dafd2 (tag)
>tagging  6bd02fb4dbee9e0fc372661af573a2ac380fed8a (commit)
>   replaces  0.6rc1
>  tagged by  David Bremner
> on  Fri Jul 1 17:08:59 2011 -0300
> 
> - Log -
> notmuch 0.6 release

w00t!  Three cheers for the Release Tyrant!  Long live the Release
Tyrant!

Here's to releasing 0.7 before 2012!

jamie.

Preventing the user shooting themself in the foot

[Jameson Graef Rollins]

On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle  wrote:
> On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  wrote:
> Non-text part: multipart/mixed
> Non-text part: multipart/signed
> 
> not sure why notmuch reply is putting that there :)

They shouldn't be, and I sent a patch to fix that a while ago:

id:"1307561409-5646-3-git-send-email-jrollins at finestructure.net"

But of course feel free to delete them before sending.

> I'm come to strongly agree that this is the Right Way to process email
> too, so should there be a keybinding for this last operation?  It should
> tag the message (or the thread?) with, say, 'task', and then proceeded
> as 'a' does.  'task' should be in the default searches you get in
> the notmuch hello buffer.

While I agree that Carl's method is pretty good, there is absolutely no
"Right Way" to process email; it's a completely personal, subjective
thing.  "Right Way" implies to me that other people *should* be
processing their mail that way, which I disagree with.

I'm generally against excessive unneeded configuration, but in the case
of key bindings it's definitely necessary.  Fortunately emacs is so
fundamentally flexible one can always modify the keybindings to their
hearts content.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: Preventing the user shooting themself in the foot

[Jameson Graef Rollins]

On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle 
michael.hud...@canonical.com wrote:
 On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@cworth.org wrote:
 Non-text part: multipart/mixed
 Non-text part: multipart/signed
 
 not sure why notmuch reply is putting that there :)

They shouldn't be, and I sent a patch to fix that a while ago:

id:1307561409-5646-3-git-send-email-jroll...@finestructure.net

But of course feel free to delete them before sending.

 I'm come to strongly agree that this is the Right Way to process email
 too, so should there be a keybinding for this last operation?  It should
 tag the message (or the thread?) with, say, 'task', and then proceeded
 as 'a' does.  'task' should be in the default searches you get in
 the notmuch hello buffer.

While I agree that Carl's method is pretty good, there is absolutely no
Right Way to process email; it's a completely personal, subjective
thing.  Right Way implies to me that other people *should* be
processing their mail that way, which I disagree with.

I'm generally against excessive unneeded configuration, but in the case
of key bindings it's definitely necessary.  Fortunately emacs is so
fundamentally flexible one can always modify the keybindings to their
hearts content.

jamie.


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

Preventing the user shooting themself in the foot

[Jameson Graef Rollins]

On Thu, 30 Jun 2011 13:04:23 +1000, Brian May  wrote:
> Are there any keyboard bindings to go forwards to the next message or
> backwards to the last message without marking anything as archived?

'n' and 'p'.  These are documented in the notmuch-show mode help ('?'
while in notmuch-show mode).

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

notmuch Digest, Vol 20, Issue 57

[Jameson Graef Rollins]

On Wed, 29 Jun 2011 14:21:11 -0600, Mark Anderson  wrote:
> I personally prefer --output=files remain as it was, with one file per
> mail (even though I submitted the patch to change it).  I suggest that
> we could add another format to supply all files (perhaps
> --output=allfiles, or --output=dupfiles).  I don't like my original
> suggestion of "filelists" because it implies a list of lists to me.  A
> list of lists would correlate better to the number of messages which
> match the search terms, but doesn't correlate well to xargs input.

What's wrong with just outputting all the files matching the search,
including duplicates?  I can't think of any reason where one would want
to not include all files matching the search.  I would be curious to
hear a use case there.

Since I'm on this kick anyway, I'm going to keep pushing against further
customizations where there really isn't a need.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Preventing the user shooting themself in the foot

[Jameson Graef Rollins]

On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green  wrote:
> It's really dangerous to use the 'a' key in notmuch-mode in an inbox
> thread which has multiple unread replies! Yes, the other unread replies
> will still be tagged unread, but the user might not immediately be aware
> of them. It would be really useful to have an optional warning ("More
> unread messages in this thread, are you sure?") for this situation!

I think that's a bit extreme, but I agree that the default behavior of
the emacs key bindings are not good, particularly in regards to
archiving messages.

I should probably just send in all of my emacs UI tweaks as patches, but
here are a couple of functions/bindings I've added to my .emacs to make
the message processing more sane.  The main new function is
notmuch-show-next-open-message-or-pop, which will jump to the next
message in the thread, or pop out of the thread if you're on the last
message.  I then use this in my tag processing functions, such as
archiving and deleting.

hth.

jamie.


(defun notmuch-show-next-open-message-or-pop ()
  "Show the next message or pop to parent search."
  (interactive)
  (let (r)
(while (and (setq r (notmuch-show-goto-message-next))
(not (notmuch-show-message-visible-p
(if r
(progn
  (notmuch-show-mark-read)
  (notmuch-show-message-adjust))
  (let ((parent-buffer notmuch-show-parent-buffer))
(if parent-buffer
(progn
  (kill-this-buffer)
  (switch-to-buffer parent-buffer)
  (forward-line 1)))

(define-key notmuch-show-mode-map "a"
  (lambda ()
"Archive current message and advance."
(interactive)
(notmuch-show-remove-tag "inbox")
(notmuch-show-next-open-message-or-pop)))

(define-key notmuch-show-mode-map "d"
  (lambda ()
"Delete current message and advance to next message."
(interactive)
(notmuch-show-add-tag "delete")
(notmuch-show-next-open-message-or-pop)))
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH 3/4] emacs: Add pseudo saved search to match mail that no saved search matches

[Jameson Graef Rollins]

On Tue, 28 Jun 2011 07:31:31 +, Jani Nikula  wrote:
> Add a pseudo saved search that matches all the mail that no other saved
> search matches. Add new customization option notmuch-saved-searches-nomatch
> to enable and name the pseudo saved search.

Hi, Jani.  I haven't looked too closely at these patches yet, although
they seem to look ok at first glance.  However, I would like to argue
*against* using new customization variables for the names of certain
static saved searches.  For instance I don't see the point of the
"notmuch-saved-searches-nomatch" and "notmuch-tags-nomatch"
customization variables.  Do people *really* need to be able to
customize those names?  Why not just pick a sensible name and go with
it?

Customization is great, but if there's too much the code and
customization UI become overly cluttered and hard to parse.

jmho

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH] test: document test_expect_equal_file

[Jameson Graef Rollins]

This test was not properly documented when it was originally added (my
bad).
---
 test/README |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/test/README b/test/README
index 8fbf78d..f9ac607 100644
--- a/test/README
+++ b/test/README
@@ -156,6 +156,13 @@ library for your script to use.
will generate a failure and print the difference of the two
strings.

+ test_expect_equal_file  
+
+   Identical to test_exepect_equal, except that  and
+are files instead of strings.  This is a much more
+   robust method to compare formatted textual information, since it
+   also notices whitespace and closing newline differences.
+
  test_expect_equal_failure  

This works similar to test_expect_equal (see above) but is used to
-- 
1.7.5.4

[PATCH] test: document test_expect_equal_file

[Jameson Graef Rollins]

This test was not properly documented when it was originally added (my
bad).
---
 test/README |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/test/README b/test/README
index 8fbf78d..f9ac607 100644
--- a/test/README
+++ b/test/README
@@ -156,6 +156,13 @@ library for your script to use.
will generate a failure and print the difference of the two
strings.
 
+ test_expect_equal_file output expected
+
+   Identical to test_exepect_equal, except that output and
+   expected are files instead of strings.  This is a much more
+   robust method to compare formatted textual information, since it
+   also notices whitespace and closing newline differences.
+
  test_expect_equal_failure output expected
 
This works similar to test_expect_equal (see above) but is used to
-- 
1.7.5.4

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

Re: [PATCH 3/4] emacs: Add pseudo saved search to match mail that no saved search matches

[Jameson Graef Rollins]

On Tue, 28 Jun 2011 07:31:31 +, Jani Nikula j...@nikula.org wrote:
 Add a pseudo saved search that matches all the mail that no other saved
 search matches. Add new customization option notmuch-saved-searches-nomatch
 to enable and name the pseudo saved search.

Hi, Jani.  I haven't looked too closely at these patches yet, although
they seem to look ok at first glance.  However, I would like to argue
*against* using new customization variables for the names of certain
static saved searches.  For instance I don't see the point of the
notmuch-saved-searches-nomatch and notmuch-tags-nomatch
customization variables.  Do people *really* need to be able to
customize those names?  Why not just pick a sensible name and go with
it?

Customization is great, but if there's too much the code and
customization UI become overly cluttered and hard to parse.

jmho

jamie.


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

Re: Preventing the user shooting themself in the foot

[Jameson Graef Rollins]

On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green gree...@greenrd.org wrote:
 It's really dangerous to use the 'a' key in notmuch-mode in an inbox
 thread which has multiple unread replies! Yes, the other unread replies
 will still be tagged unread, but the user might not immediately be aware
 of them. It would be really useful to have an optional warning (More
 unread messages in this thread, are you sure?) for this situation!

I think that's a bit extreme, but I agree that the default behavior of
the emacs key bindings are not good, particularly in regards to
archiving messages.

I should probably just send in all of my emacs UI tweaks as patches, but
here are a couple of functions/bindings I've added to my .emacs to make
the message processing more sane.  The main new function is
notmuch-show-next-open-message-or-pop, which will jump to the next
message in the thread, or pop out of the thread if you're on the last
message.  I then use this in my tag processing functions, such as
archiving and deleting.

hth.

jamie.


(defun notmuch-show-next-open-message-or-pop ()
  Show the next message or pop to parent search.
  (interactive)
  (let (r)
(while (and (setq r (notmuch-show-goto-message-next))
(not (notmuch-show-message-visible-p
(if r
(progn
  (notmuch-show-mark-read)
  (notmuch-show-message-adjust))
  (let ((parent-buffer notmuch-show-parent-buffer))
(if parent-buffer
(progn
  (kill-this-buffer)
  (switch-to-buffer parent-buffer)
  (forward-line 1)))

(define-key notmuch-show-mode-map a
  (lambda ()
Archive current message and advance.
(interactive)
(notmuch-show-remove-tag inbox)
(notmuch-show-next-open-message-or-pop)))

(define-key notmuch-show-mode-map d
  (lambda ()
Delete current message and advance to next message.
(interactive)
(notmuch-show-add-tag delete)
(notmuch-show-next-open-message-or-pop)))


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

Re: [PATCH 3/4] emacs: Add pseudo saved search to match mail that no saved search matches

[Jameson Graef Rollins]

On Wed, 29 Jun 2011 20:15:22 +, Jani Nikula j...@nikula.org wrote:
 So to clarify, do you prefer having on/off switches, or just enabling
 this without customization at all? Personally I'd shy away from the
 latter, but I guess it depends on how useful vs. distracting people find
 this.

My opinion is to just make it a feature without any customization at
all.  I can see no harm in having these searches always available.

jamie.


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

Notmuch 0.6: Let's do it.

[Jameson Graef Rollins]

On Wed, 22 Jun 2011 22:26:06 -0300, David Bremner  wrote:
> 3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now
>and July 1.

Hi, David.  You might want to consider applying the following patches
for 0.6:

Bug fix for raw output of gmime parts:
  id:"1307120466-4980-1-git-send-email-jrollins at finestructure.net"

Series to fix rfc822 handling:
  id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net"

The later fixes what is probably consider a regression in rfc822
handling.  I think we'll be able to improve this handling a lot in 0.7
(with the help of some work that Austin is doing), but these fixes
should tide us over until then.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH] Do not attept to output part raw if part is not GMimePart.

[Jameson Graef Rollins]

On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth  wrote:
> I'd like to investigate this case a little bit to help answer the
> question of whether "notmuch should have done anything in this case".

Hi, Carl.  You can see this error if you try to output raw a multipart/*
or message/rfc822 part, ie:

servo:~ 0$ notmuch show --part=1 --format=raw id:"87wrgccedd.fsf at 
yoom.home.cworth.org" >/dev/null

(process:29838): GLib-GObject-WARNING **: invalid cast from 
`GMimeMultipartSigned' to `GMimePart'

(process:29838): gmime-CRITICAL **: g_mime_part_get_content_object: assertion 
`GMIME_IS_PART (mime_part)' failed
servo:~ 0$ 

Gmime seems to be successfully casting the part into GMimePart and then
outputting the content, but it does produce the warning on stderr.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH] Do not attept to output part raw if part is not GMimePart.

[Jameson Graef Rollins]

On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth cwo...@cworth.org wrote:
 I'd like to investigate this case a little bit to help answer the
 question of whether notmuch should have done anything in this case.

Hi, Carl.  You can see this error if you try to output raw a multipart/*
or message/rfc822 part, ie:

servo:~ 0$ notmuch show --part=1 --format=raw 
id:87wrgccedd@yoom.home.cworth.org /dev/null

(process:29838): GLib-GObject-WARNING **: invalid cast from 
`GMimeMultipartSigned' to `GMimePart'

(process:29838): gmime-CRITICAL **: g_mime_part_get_content_object: assertion 
`GMIME_IS_PART (mime_part)' failed
servo:~ 0$ 

Gmime seems to be successfully casting the part into GMimePart and then
outputting the content, but it does produce the warning on stderr.

jamie.


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

Re: Notmuch 0.6: Let's do it.

[Jameson Graef Rollins]

On Wed, 22 Jun 2011 22:26:06 -0300, David Bremner da...@tethera.net wrote:
 3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now
and July 1.

Hi, David.  You might want to consider applying the following patches
for 0.6:

Bug fix for raw output of gmime parts:
  id:1307120466-4980-1-git-send-email-jroll...@finestructure.net

Series to fix rfc822 handling:
  id:1307320169-29905-1-git-send-email-jroll...@finestructure.net

The later fixes what is probably consider a regression in rfc822
handling.  I think we'll be able to improve this handling a lot in 0.7
(with the help of some work that Austin is doing), but these fixes
should tide us over until then.

jamie.


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

Re: [PATCH] Do not attept to output part raw if part is not GMimePart.

[Jameson Graef Rollins]

On Mon, 27 Jun 2011 16:43:36 -0400, Austin Clements amdra...@mit.edu wrote:
 Just to clarify my understanding, --format=raw is only intended to
 work on either the whole message (special-cased in do_show_single) or
 a leaf MIME part, and in any other case, it will output nothing?  The
 raw output test cases seem pretty thin.

Hey, Austin.  The raw part output works for *any* part, be it leaf part,
multipart, message/rfc822, etc.  I added a bunch of tests for raw part
output that should cover all of this, although I don't think they've
been pulled into master yet.

I think there are a lot of open questions about what should be output
for multipart raw.  We should output _something_, though.  I think we
can fix all of this up for 0.7, based on the work you've already done,
after 0.6 is released.

jamie.


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

Race condition for '*' command

[Jameson Graef Rollins]

On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green  wrote:
> A race condition in the '*' command was noted when it was first
> proposed. It looks to me like it still exists - has anything been done
> about it?

Hi, Robin.  Can you explain what you mean by the "'*' command"?  Are you
referring to '*' as a search term?  It's not a command, but it's the
only place I know of where notmuch uses the '*' character.  Can you
explain in a little more detail what exactly your issue is?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: Race condition for '*' command

[Jameson Graef Rollins]

On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green gree...@greenrd.org wrote:
 A race condition in the '*' command was noted when it was first
 proposed. It looks to me like it still exists - has anything been done
 about it?

Hi, Robin.  Can you explain what you mean by the '*' command?  Are you
referring to '*' as a search term?  It's not a command, but it's the
only place I know of where notmuch uses the '*' character.  Can you
explain in a little more detail what exactly your issue is?

jamie.


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

Debian package not building

[Jameson Graef Rollins]

Hey, folks.  As of today I am for some reason no longer able to build
the Notmuch Debian package.  I'm using the same build technique I have
been using for a while (git-buildpackage).  The tail of the failing
build log is pasted at the bottom of this message.  Is anyone else
encountering anything like this?

I don't see what of the recent packaging changes, other than the RPATH
stuff, could be affecting this, and I get the same failure even if I
revert the revert of the RPATH override (ie. RPATH_LDFLAGS auto-build
override in place).  I did recently do a system upgrade, so it's
possible that something there could have caused the problem.

What could be preventing dpkg-shlibdeps from finding libpthread.so.0 or
libc.so.6?

jamie.


servo:~/src/notmuch/git [master] 1$ git buildpackage -us -uc --git-ignore-branch
...
dpkg-shlibdeps: error: couldn't find library libpthread.so.0 needed by 
debian/notmuch/usr/bin/notmuch (ELF format: 'elf64-x86-64'; RPATH: '').
dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by 
debian/notmuch/usr/bin/notmuch (ELF format: 'elf64-x86-64'; RPATH: '').
dpkg-shlibdeps: error: Cannot continue due to the errors listed above.
Note: libraries are not searched in other binary packages that do not have any 
shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to set 
LD_LIBRARY_PATH.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/notmuch.substvars 
debian/notmuch/usr/bin/notmuch returned exit code 2
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1340:
dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed
gbp:error: debuild -i -I returned 29
gbp:error: Couldn't run 'debuild -i -I -us -uc'
servo:~/src/notmuch/git [master] 1$ 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: Notmuch 0.6: Let's do it.

[Jameson Graef Rollins]

On Thu, 23 Jun 2011 09:13:05 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 Me bows to the tyrant and the hard-working henchmen. :)

We (henchmen) generally prefer to go by the official title of
Interim Distinguished co-Chief Vice Tyrant.

jamie.


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

[PATCH] emacs: Show all multipart/alternative parts by default.

[Jameson Graef Rollins]

This is patch is a temporary work-around for a slight regression that
popped up in the part handling reorganization.  Currently, text/plain
parts are always preferred, if present, over other non-text/plain
parts in multipart/alternative.  However, this means that if there is
a blank text/plain part, no content will be displayed.

One way to get around this is to set the
"notmuch-show-all-multipart/alternative-parts" customization variable
to True ('t'), which will cause all parts to always be displayed.

Since we want to move forward with the next release, we're going to
set this variable true by default, to make sure that no content is
unretrievably hidden from the user.  Once we come up with a better
solution for easy display of hidden parts we can set this back to a
default value of 'nil'.
---
 emacs/notmuch-show.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 0d9b52a..af1d44b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -96,7 +96,7 @@ same as that of the previous message."
 notmuch-wash-excerpt-citations))

 ;; Mostly useful for debugging.
-(defcustom notmuch-show-all-multipart/alternative-parts nil
+(defcustom notmuch-show-all-multipart/alternative-parts t
   "Should all parts of multipart/alternative parts be shown?"
   :group 'notmuch
   :type 'boolean)
-- 
1.7.5.4

I feel a release coming!

[Jameson Graef Rollins]

I think we just agreed with cworth on irc that this simple patch will
satisfy his regression worry for 0.6.  Meaning that we can push out
the release after this patch is merged.

bremner, our new "Release Tyrant", has his finger on the trigger...

[PATCH] emacs: Show all multipart/alternative parts by default.

[Jameson Graef Rollins]

This is patch is a temporary work-around for a slight regression that
popped up in the part handling reorganization.  Currently, text/plain
parts are always preferred, if present, over other non-text/plain
parts in multipart/alternative.  However, this means that if there is
a blank text/plain part, no content will be displayed.

One way to get around this is to set the
notmuch-show-all-multipart/alternative-parts customization variable
to True ('t'), which will cause all parts to always be displayed.

Since we want to move forward with the next release, we're going to
set this variable true by default, to make sure that no content is
unretrievably hidden from the user.  Once we come up with a better
solution for easy display of hidden parts we can set this back to a
default value of 'nil'.
---
 emacs/notmuch-show.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 0d9b52a..af1d44b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -96,7 +96,7 @@ same as that of the previous message.
 notmuch-wash-excerpt-citations))
 
 ;; Mostly useful for debugging.
-(defcustom notmuch-show-all-multipart/alternative-parts nil
+(defcustom notmuch-show-all-multipart/alternative-parts t
   Should all parts of multipart/alternative parts be shown?
   :group 'notmuch
   :type 'boolean)
-- 
1.7.5.4

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

[PATCH 2/2] debian: break up Build-Depends on separate lines

[Jameson Graef Rollins]

---
 debian/control |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 90bd0ee..3289282 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,15 @@ Uploaders:
  martin f. krafft ,
  Jameson Graef Rollins ,
  David Bremner ,
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ pkg-config,
+ libxapian-dev,
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs23-nox,
+ python-all (>= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

[PATCH 1/2] debian: break up uploaders on separate lines

[Jameson Graef Rollins]

---
 debian/control |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 4b60af0..90bd0ee 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,10 @@ Source: notmuch
 Section: mail
 Priority: extra
 Maintainer: Carl Worth 
-Uploaders: martin f. krafft , 
-  Jameson Graef Rollins ,
-  David Bremner 
+Uploaders:
+ martin f. krafft ,
+ Jameson Graef Rollins ,
+ David Bremner ,
 Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
  libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
  python-all (>= 2.6.6-3~)
-- 
1.7.5.3

No subject

[Jameson Graef Rollins]

hrm, sorry.  Looks like those last two patches got a little messed up.
These two patches replace the previous two.

jamie.

[PATCH 4/4] debian: bump standards version to 3.9.2

[Jameson Graef Rollins]

---
 debian/control |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 49f6961..52c2e5a 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
  libz-dev,
  emacs23 | emacs23-nox,
  python-all (>= 2.6.6-3~),
-Standards-Version: 3.9.1.0
+Standards-Version: 3.9.2
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
 Vcs-Browser: http://git.notmuchmail.org/git/notmuch
-- 
1.7.5.3

[PATCH 3/4] debian: build depend on emacs23 or emacs23-nox

[Jameson Graef Rollins]

---
 debian/control |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 0c998df..49f6961 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
  libgmime-2.4-dev,
  libtalloc-dev,
  libz-dev,
- emacs23-nox,
+ emacs23 | emacs23-nox,
  python-all (>= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
-- 
1.7.5.3

[PATCH 2/4] debian: break up Build-Depends on separate lines

[Jameson Graef Rollins]

---
 debian/control |   14 ++
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 51353de..0c998df 100644
--- a/debian/control
+++ b/debian/control
@@ -3,12 +3,18 @@ Section: mail
 Priority: extra
 Maintainer: Carl Worth 
 Uploaders:
- martin f. krafft , 
+ martin f. krafft ,
  Jameson Graef Rollins ,
  David Bremner ,
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ pkg-config,
+ libxapian-dev, 
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs23-nox,
+ python-all (>= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

[PATCH 1/4] debian: break up uploaders on separate lines

[Jameson Graef Rollins]

---
 debian/control |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 4b60af0..51353de 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,10 @@ Source: notmuch
 Section: mail
 Priority: extra
 Maintainer: Carl Worth 
-Uploaders: martin f. krafft , 
-  Jameson Graef Rollins ,
-  David Bremner 
+Uploaders:
+ martin f. krafft , 
+ Jameson Graef Rollins ,
+ David Bremner ,
 Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
  libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
  python-all (>= 2.6.6-3~)
-- 
1.7.5.3

[PATCH 4/4] debian: bump standards version to 3.9.2

[Jameson Graef Rollins]

---
 debian/control |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 49f6961..52c2e5a 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
  libz-dev,
  emacs23 | emacs23-nox,
  python-all (= 2.6.6-3~),
-Standards-Version: 3.9.1.0
+Standards-Version: 3.9.2
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
 Vcs-Browser: http://git.notmuchmail.org/git/notmuch
-- 
1.7.5.3

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

[PATCH 2/4] debian: break up Build-Depends on separate lines

[Jameson Graef Rollins]

---
 debian/control |   14 ++
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 51353de..0c998df 100644
--- a/debian/control
+++ b/debian/control
@@ -3,12 +3,18 @@ Section: mail
 Priority: extra
 Maintainer: Carl Worth cwo...@debian.org
 Uploaders:
- martin f. krafft madd...@debian.org, 
+ martin f. krafft madd...@debian.org,
  Jameson Graef Rollins jroll...@finestructure.net,
  David Bremner brem...@debian.org,
-Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (= 2.6.6-3~)
+Build-Depends:
+ debhelper (= 7.0.50~),
+ pkg-config,
+ libxapian-dev, 
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs23-nox,
+ python-all (= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

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

[PATCH 1/4] debian: break up uploaders on separate lines

[Jameson Graef Rollins]

---
 debian/control |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 4b60af0..51353de 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,10 @@ Source: notmuch
 Section: mail
 Priority: extra
 Maintainer: Carl Worth cwo...@debian.org
-Uploaders: martin f. krafft madd...@debian.org, 
-  Jameson Graef Rollins jroll...@finestructure.net,
-  David Bremner brem...@debian.org
+Uploaders:
+ martin f. krafft madd...@debian.org, 
+ Jameson Graef Rollins jroll...@finestructure.net,
+ David Bremner brem...@debian.org,
 Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
  libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
  python-all (= 2.6.6-3~)
-- 
1.7.5.3

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

[PATCH 3/4] debian: build depend on emacs23 or emacs23-nox

[Jameson Graef Rollins]

---
 debian/control |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 0c998df..49f6961 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
  libgmime-2.4-dev,
  libtalloc-dev,
  libz-dev,
- emacs23-nox,
+ emacs23 | emacs23-nox,
  python-all (= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
-- 
1.7.5.3

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

[no subject]

[Jameson Graef Rollins]

hrm, sorry.  Looks like those last two patches got a little messed up.
These two patches replace the previous two.

jamie.

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

[PATCH 1/2] debian: break up uploaders on separate lines

[Jameson Graef Rollins]

---
 debian/control |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 4b60af0..90bd0ee 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,10 @@ Source: notmuch
 Section: mail
 Priority: extra
 Maintainer: Carl Worth cwo...@debian.org
-Uploaders: martin f. krafft madd...@debian.org, 
-  Jameson Graef Rollins jroll...@finestructure.net,
-  David Bremner brem...@debian.org
+Uploaders:
+ martin f. krafft madd...@debian.org,
+ Jameson Graef Rollins jroll...@finestructure.net,
+ David Bremner brem...@debian.org,
 Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
  libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
  python-all (= 2.6.6-3~)
-- 
1.7.5.3

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

[PATCH 2/2] debian: break up Build-Depends on separate lines

[Jameson Graef Rollins]

---
 debian/control |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 90bd0ee..3289282 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,15 @@ Uploaders:
  martin f. krafft madd...@debian.org,
  Jameson Graef Rollins jroll...@finestructure.net,
  David Bremner brem...@debian.org,
-Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (= 2.6.6-3~)
+Build-Depends:
+ debhelper (= 7.0.50~),
+ pkg-config,
+ libxapian-dev,
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs23-nox,
+ python-all (= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

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

bug in emacs-ui ?

[Jameson Graef Rollins]

On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet  
wrote:
> and I checked there were no lingering .el files...
> 
> so...
>  any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
> when comes to hacking lisp)

Hey, Sebastien.  You can determine the loaded version of a library from
within emacs with the follow command:

M-x locate-library notmuch

It's also good to know how many notmuch instances are installed on your
system.  For instance, I have a system-wide installation, a "personal"
installation, the build currently in the source tree, etc.  Depending on
the options I supply to emacs at startup, I could run a variety of
versions.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

bug in emacs-ui ?

[Jameson Graef Rollins]

On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet  
wrote:
> > You didn't try forwarding the email to the list ;)
> ah! that easy, heh ?
> 
Attachment: 
1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S 
(application/octet-stream)

Hi, Sebastien.  I don't seem to have any problems viewing this message
with notmuch emacs.  Is it possible that the notmuch emacs code you're
running is out-of-sync with your notmuch binary?  I think that's a
common source of problems like this.  Make sure that you're pointed to
the version of the notmuch emacs libraries that corresponds to your
notmuch binary, and that you've restarted your emacs session.  Hopefully
that will fix things.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

bug in emacs-ui ?

[Jameson Graef Rollins]

On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet  
wrote:
> > You didn't try forwarding the email to the list ;)
> ah! that easy, heh ?
>
> Attachment: 
> 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
>  (application/octet-stream)

Are you sure this is the right message?  This message doesn't include
any signature section that looks like the one that you posted before.
The one you posted in your previous message was:

___
Message sent via/by LCG Savannah
http://savannah.cern.ch/

This one is:

___
announce mailing list
announce at open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/announce

Also (unrelated) I notice that the above attached message is not
content-type "message/rfc822".  Specifying the right content type helps 
receivers handle the messages a little better.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

bug in emacs-ui ?

[Jameson Graef Rollins]

On Mon, 20 Jun 2011 17:52:03 +0200, Sebastien Binet  
wrote:
> it is only when the signature is lumped like below, that I get the error:
>   [ 4-line signature. Click/Enter to show. ]
> 
> also, it's only happening to the last message of a thread.

Ah, ok.  Have you tried looking at the raw message?  Are there any
strange characters or content after the signatures?

> > If you feel comfortable doing so, it might help to forward the suspect
> > message to the list.
> 
> I tried all the above, to no avail (ie: nothing on stderr.)

You didn't try forwarding the email to the list ;)

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

bug in emacs-ui ?

[Jameson Graef Rollins]

On Mon, 20 Jun 2011 09:15:06 +0200, Sebastien Binet  
wrote:
> recently, using the head of notmuch-git:
> 
>  git://notmuchmail.org/git/notmuch
> 
> when a mail ends with an url and is recognized as a signature:
...
> I can't hit [space] to go to the next thread and I get the following
> error:
>  End of buffer

Hey, Sebastien.  I'm guessing that it is probably the *next* message in
the thread that is the problem, not the end of the one that you're
seeing.  If you can determine the message id's of this message and the
next one in the thread it will probably help with debugging.

If you haven't yet, it usually helps in debugging to view the messages
in the terminal?  You can copy the thread-id into the clipboard by
hitting "c i" when the cursor is over this thread in the notmuch search
buffer, and then you can view the thread on the command line with:

  notmuch show thread:

It might be hard to see if there are any problems in the output, but you
can at least see gmime is throwing an error by redirecting stdout to
/dev/null:

  notmuch show thread: >/dev/null

You can try determining the message-ids with something like:

  notmuch show thread: | grep id

You can then view the raw messages with:

  notmuch show --format=raw id:

If you feel comfortable doing so, it might help to forward the suspect
message to the list.

> this does not show up when using the 'release-candidate/0.6' branch of:
>  git://finestructure.net/notmuch

The release-candidate/0.6 is a bit out-of-date at the moment, as most of
it's features have been incorporate into notmuch/master, and I doubt
that the ones that haven't would be related to the issue you're seeing.

hth.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: bug in emacs-ui ?

[Jameson Graef Rollins]

On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet seb.bi...@gmail.com wrote:
  You didn't try forwarding the email to the list ;)
 ah! that easy, heh ?

 Attachment: 
 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
  (application/octet-stream)

Are you sure this is the right message?  This message doesn't include
any signature section that looks like the one that you posted before.
The one you posted in your previous message was:

___
Message sent via/by LCG Savannah
http://savannah.cern.ch/

This one is:

___
announce mailing list
annou...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/announce

Also (unrelated) I notice that the above attached message is not
content-type message/rfc822.  Specifying the right content type helps 
receivers handle the messages a little better.

jamie.


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

[PATCH] debian: break up build-depends on separate lines

[Jameson Graef Rollins]

For clarity and cleaner future diffs.
---
 debian/control |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index fa5f762..8ffa22b 100644
--- a/debian/control
+++ b/debian/control
@@ -3,9 +3,15 @@ Section: mail
 Priority: extra
 Maintainer: Carl Worth 
 Uploaders: Jameson Graef Rollins , martin f. 
krafft 
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs (>= 23~), 
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ pkg-config,
+ libxapian-dev,
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs (>= 23~),
+ python-all (>= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

[PATCH] debian: break up build-depends on separate lines

[Jameson Graef Rollins]

For clarity and cleaner future diffs.
---
 debian/control |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index fa5f762..8ffa22b 100644
--- a/debian/control
+++ b/debian/control
@@ -3,9 +3,15 @@ Section: mail
 Priority: extra
 Maintainer: Carl Worth cwo...@debian.org
 Uploaders: Jameson Graef Rollins jroll...@finestructure.net, martin f. 
krafft madd...@debian.org
-Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs (= 23~), 
- python-all (= 2.6.6-3~)
+Build-Depends:
+ debhelper (= 7.0.50~),
+ pkg-config,
+ libxapian-dev,
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs (= 23~),
+ python-all (= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

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

[PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Jameson Graef Rollins]

On Wed, 15 Jun 2011 18:25:14 +0400, Dmitry Kurochkin  wrote:
> I know you prefer tests to go before patches and I agree with that.  But
> most of the time I do tests after coding.  I do not know an easy way to
> reorder patches in git.  (Also I do not know how to amend an old patch,
> wish more darcs features in git.)  Hopefully it is not a big trouble for
> you to reorder the patches when applying.

Hey, Dmitry.  I usually just pop in to a new branch rooted before my new
patch series, and then cherry-pick the new patches onto the branch in
the order I want (eg. tests first, etc.).

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH] emacs: Add callback functions to crypto sigstatus button.

[Jameson Graef Rollins]

On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins  wrote:
> This adds two callback functions to the sigstatus button.  If the sig
> status is "good", then clicking the button displays the output of "gpg
> --list-keys" on the key fingerprint.  If the sigstatus is "bad", then
> clicking the button will retrieve the key from the keyserver, and
> redisplay the current buffer.
> 
> Thanks to David Bremner  for help with this.

I just want to point out for the record that this patch depends on the
patch series starting at:

id:"1306627784-3401-1-git-send-email-jrollins at finestructure.net"

Sorry for the mixup.

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/20110614/58a89eb0/attachment.pgp>

Re: [PATCH] emacs: Add callback functions to crypto sigstatus button.

[Jameson Graef Rollins]

On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 This adds two callback functions to the sigstatus button.  If the sig
 status is good, then clicking the button displays the output of gpg
 --list-keys on the key fingerprint.  If the sigstatus is bad, then
 clicking the button will retrieve the key from the keyserver, and
 redisplay the current buffer.
 
 Thanks to David Bremner brem...@unb.ca for help with this.

I just want to point out for the record that this patch depends on the
patch series starting at:

id:1306627784-3401-1-git-send-email-jroll...@finestructure.net

Sorry for the mixup.

jamie.


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

Re: [PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Jameson Graef Rollins]

On Wed, 15 Jun 2011 18:25:14 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 I know you prefer tests to go before patches and I agree with that.  But
 most of the time I do tests after coding.  I do not know an easy way to
 reorder patches in git.  (Also I do not know how to amend an old patch,
 wish more darcs features in git.)  Hopefully it is not a big trouble for
 you to reorder the patches when applying.

Hey, Dmitry.  I usually just pop in to a new branch rooted before my new
patch series, and then cherry-pick the new patches onto the branch in
the order I want (eg. tests first, etc.).

jamie.


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

[PATCH 3/3] emacs: Test for thread-outlining

[Jameson Graef Rollins]

On Tue, 14 Jun 2011 21:58:48 +0530, "Aneesh Kumar K.V"  wrote:
> Lars Kellogg-Stedman  - 2009-11-17
> |-> Mikhail Gusarov  - 2009-11-17
> |-> Lars Kellogg-Stedman  - 2009-11-17
> |->"Mikhail Gusarov"  - 2009-11-17
> |->"Keith Packard"  - 2009-11-17

Or better yet:

?? Lars Kellogg-Stedman  - 2009-11-17
??? Mikhail Gusarov  - 2009-11-17
 Lars Kellogg-Stedman  - 2009-11-17
? ?? Mikhail Gusarov  - 2009-11-17
? ?? Keith Packard  - 2009-11-17
?-- Foo Bar  - 2009-11-18

I actually started working on something like this, but I haven't had
time to finish.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH 3/3] emacs: Test for thread-outlining

[Jameson Graef Rollins]

On Tue, 14 Jun 2011 21:58:48 +0530, Aneesh Kumar K.V 
aneesh.ku...@linux.vnet.ibm.com wrote:
 Lars Kellogg-Stedman l...@seas.harvard.edu - 2009-11-17
 |- Mikhail Gusarov dotted...@dottedmag.net - 2009-11-17
 |- Lars Kellogg-Stedman l...@seas.harvard.edu - 2009-11-17
 |-Mikhail Gusarov dotted...@dottedmag.net - 2009-11-17
 |-Keith Packard kei...@keithp.com - 2009-11-17

Or better yet:

┬╴ Lars Kellogg-Stedman l...@seas.harvard.edu - 2009-11-17
├┬╴ Mikhail Gusarov dotted...@dottedmag.net - 2009-11-17
│└┬╴ Lars Kellogg-Stedman l...@seas.harvard.edu - 2009-11-17
│ ├╴ Mikhail Gusarov dotted...@dottedmag.net - 2009-11-17
│ └╴ Keith Packard kei...@keithp.com - 2009-11-17
└-- Foo Bar foo...@example.com - 2009-11-18

I actually started working on something like this, but I haven't had
time to finish.

jamie.


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

[PATCH 4/4] Ignore "application/pgp-*" parts in reply.

[Jameson Graef Rollins]

The quoted text doesn't need to mention that the message being replied
to had these crufty parts.
---
 notmuch-reply.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7a76ba3..0eb295e 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -98,6 +98,11 @@ reply_part_content (GMimeObject *part)
 {
/* Output nothing, since multipart subparts will be handled 
individually. */
 }
+else if (g_mime_content_type_is_type (content_type, "application", 
"pgp-encrypted") ||
+g_mime_content_type_is_type (content_type, "application", 
"pgp-signature"))
+{
+   /* Ignore PGP/MIME cruft parts */
+}
 else if (g_mime_content_type_is_type (content_type, "text", "*") &&
!g_mime_content_type_is_type (content_type, "text", "html"))
 {
-- 
1.7.5.3

[PATCH 3/4] test: test for absence of "Non-text part: application/pgp-*" lines in reply

[Jameson Graef Rollins]

In reply, the quoted text does not need to mention that the original
message had "application/pgp-signed" or "application/pgp-encrypted"
parts.
---
 test/crypto|2 --
 test/multipart |1 -
 2 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/test/crypto b/test/crypto
index 8e92016..cf096c0 100755
--- a/test/crypto
+++ b/test/crypto
@@ -310,8 +310,6 @@ expected='From: Notmuch Test Suite 
 Subject: Re: test encrypted message 002

 On 01 Jan 2000 12:00:00 -, Notmuch Test Suite  wrote:
-Non-text part: multipart/encrypted
-Non-text part: application/pgp-encrypted
 > This is another test encrypted message.'
 test_expect_equal \
 "$output" \
diff --git a/test/multipart b/test/multipart
index c7431cc..e333a67 100755
--- a/test/multipart
+++ b/test/multipart
@@ -589,7 +589,6 @@ Non-text part: text/html
 > And this message is signed.
 > 
 > -Carl
-Non-text part: application/pgp-signature
 EOF
 test_expect_equal_file OUTPUT EXPECTED

-- 
1.7.5.3

[PATCH 2/4] Fix notmuch-reply to not output "Non-text part:" lines for non-leafnode parts.

[Jameson Graef Rollins]

These lines are just cruft in this case, and can be removed.
---
 notmuch-reply.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index a19eb19..7a76ba3 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -93,7 +93,12 @@ reply_part_content (GMimeObject *part)
 GMimeContentType *content_type = g_mime_object_get_content_type 
(GMIME_OBJECT (part));
 GMimeContentDisposition *disposition = 
g_mime_object_get_content_disposition (part);

-if (g_mime_content_type_is_type (content_type, "text", "*") &&
+if (g_mime_content_type_is_type (content_type, "multipart", "*") ||
+   g_mime_content_type_is_type (content_type, "message", "rfc822"))
+{
+   /* Output nothing, since multipart subparts will be handled 
individually. */
+}
+else if (g_mime_content_type_is_type (content_type, "text", "*") &&
!g_mime_content_type_is_type (content_type, "text", "html"))
 {
GMimeStream *stream_stdout = NULL, *stream_filter = NULL;
@@ -120,10 +125,6 @@ reply_part_content (GMimeObject *part)
if (stream_stdout)
g_object_unref(stream_stdout);
 }
-else if (g_mime_content_type_is_type (content_type, "message", "rfc822"))
-{
-   /* Output nothing, since rfc822 subparts will be handled individually. 
*/
-}
 else
 {
if (disposition &&
-- 
1.7.5.3

[PATCH 1/4] test/multipart: test for absence of "Non-text part:" lines in reply for multipart/* and message/rfc822 parts

[Jameson Graef Rollins]

There's no reason to output "Non-text part:" lines for parts that are
not leaf nodes, eg. multipart/* and message/rfc822.  We fix the text
here to test for their absence.  The next patch will fix reply
accordingly.
---
 test/multipart |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/test/multipart b/test/multipart
index 95577dc..c7431cc 100755
--- a/test/multipart
+++ b/test/multipart
@@ -578,14 +578,11 @@ In-Reply-To: <87liy5ap00.fsf at yoom.home.cworth.org>
 References: <87liy5ap00.fsf at yoom.home.cworth.org>

 On Fri, 05 Jan 2001 15:43:57 +, Carl Worth  wrote:
-Non-text part: multipart/signed
-Non-text part: multipart/mixed
 > From: Carl Worth 
 > To: cworth at cworth.org
 > Subject: html message
 > Date: Fri, 05 Jan 2001 15:42:57 +
 >
-Non-text part: multipart/alternative
 Non-text part: text/html
 > This is an embedded message, with a multipart/alternative part.
 > This is a text attachment.
-- 
1.7.5.3

tweaks for handling parts in reply

[Jameson Graef Rollins]

This is a small set of tweaks to remove unneccessary "Non-text part:"
lines in reply, for parts that really don't need to be mentioned.

This patch set is not really related to the series that it is being
sent in reply to, but it has been worked on top of the message/rfc822
rework of the multipart test, so it's being sent in reply to that
message.

jamie.

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal  
wrote:
> After a conversation with David last year about bug-tracking, I worked
> up a rough python-based prototype of this. It worked in terms of
> namespaces, so Carl could associate the namespace "public" with a list
> of tags he publishes to a http-accessable location. And you could
> associate the namespace "cworth" with those same tags.

This sounds very cool, Jesse.  Very git-like.  I like it.

> You type `whatevercommand pull cworth` and the tags come down from that
> URL as "cworth.*".
> 
> So what he has as "public.to-push" comes down to your notmuch as
> "cworth.to-push".

Did you guys try to address the issue of tag removal at all?  I've been
trying to decide if this is something we need to worry about or not.
For instance, if cworth pushed a tag ".needs-review", you would probably
want to have that tag removed if cworth removed it.  I guess
alternatively he could just push the tag ".reviewed" to nullify the
meaning of the previous one.  I'm not sure that would work in all cases,
though.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 After a conversation with David last year about bug-tracking, I worked
 up a rough python-based prototype of this. It worked in terms of
 namespaces, so Carl could associate the namespace public with a list
 of tags he publishes to a http-accessable location. And you could
 associate the namespace cworth with those same tags.

This sounds very cool, Jesse.  Very git-like.  I like it.

 You type `whatevercommand pull cworth` and the tags come down from that
 URL as cworth.*.
 
 So what he has as public.to-push comes down to your notmuch as
 cworth.to-push.

Did you guys try to address the issue of tag removal at all?  I've been
trying to decide if this is something we need to worry about or not.
For instance, if cworth pushed a tag .needs-review, you would probably
want to have that tag removed if cworth removed it.  I guess
alternatively he could just push the tag .reviewed to nullify the
meaning of the previous one.  I'm not sure that would work in all cases,
though.

jamie.


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

[PATCH 4/4] Ignore application/pgp-* parts in reply.

[Jameson Graef Rollins]

The quoted text doesn't need to mention that the message being replied
to had these crufty parts.
---
 notmuch-reply.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7a76ba3..0eb295e 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -98,6 +98,11 @@ reply_part_content (GMimeObject *part)
 {
/* Output nothing, since multipart subparts will be handled 
individually. */
 }
+else if (g_mime_content_type_is_type (content_type, application, 
pgp-encrypted) ||
+g_mime_content_type_is_type (content_type, application, 
pgp-signature))
+{
+   /* Ignore PGP/MIME cruft parts */
+}
 else if (g_mime_content_type_is_type (content_type, text, *) 
!g_mime_content_type_is_type (content_type, text, html))
 {
-- 
1.7.5.3

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

[PATCH 2/4] Fix notmuch-reply to not output Non-text part: lines for non-leafnode parts.

[Jameson Graef Rollins]

These lines are just cruft in this case, and can be removed.
---
 notmuch-reply.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index a19eb19..7a76ba3 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -93,7 +93,12 @@ reply_part_content (GMimeObject *part)
 GMimeContentType *content_type = g_mime_object_get_content_type 
(GMIME_OBJECT (part));
 GMimeContentDisposition *disposition = 
g_mime_object_get_content_disposition (part);
 
-if (g_mime_content_type_is_type (content_type, text, *) 
+if (g_mime_content_type_is_type (content_type, multipart, *) ||
+   g_mime_content_type_is_type (content_type, message, rfc822))
+{
+   /* Output nothing, since multipart subparts will be handled 
individually. */
+}
+else if (g_mime_content_type_is_type (content_type, text, *) 
!g_mime_content_type_is_type (content_type, text, html))
 {
GMimeStream *stream_stdout = NULL, *stream_filter = NULL;
@@ -120,10 +125,6 @@ reply_part_content (GMimeObject *part)
if (stream_stdout)
g_object_unref(stream_stdout);
 }
-else if (g_mime_content_type_is_type (content_type, message, rfc822))
-{
-   /* Output nothing, since rfc822 subparts will be handled individually. 
*/
-}
 else
 {
if (disposition 
-- 
1.7.5.3

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

[PATCH 3/4] test: test for absence of Non-text part: application/pgp-* lines in reply

[Jameson Graef Rollins]

In reply, the quoted text does not need to mention that the original
message had application/pgp-signed or application/pgp-encrypted
parts.
---
 test/crypto|2 --
 test/multipart |1 -
 2 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/test/crypto b/test/crypto
index 8e92016..cf096c0 100755
--- a/test/crypto
+++ b/test/crypto
@@ -310,8 +310,6 @@ expected='From: Notmuch Test Suite 
test_su...@notmuchmail.org
 Subject: Re: test encrypted message 002
 
 On 01 Jan 2000 12:00:00 -, Notmuch Test Suite test_su...@notmuchmail.org 
wrote:
-Non-text part: multipart/encrypted
-Non-text part: application/pgp-encrypted
  This is another test encrypted message.'
 test_expect_equal \
 $output \
diff --git a/test/multipart b/test/multipart
index c7431cc..e333a67 100755
--- a/test/multipart
+++ b/test/multipart
@@ -589,7 +589,6 @@ Non-text part: text/html
  And this message is signed.
  
  -Carl
-Non-text part: application/pgp-signature
 EOF
 test_expect_equal_file OUTPUT EXPECTED
 
-- 
1.7.5.3

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

When will we have our next release?

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth  wrote:
> Frankly, I wouldn't mind doing strict time-based releases with something
> like the following:

Hi, Carl.  I think this is a fine idea, and we (not you) can definitely
run this process.  I'm quite sure that at least bremner and I can
completely handle this together, and I'm sure we can get others to help.

But the mechanics of the actual release are not the problem.  The
problem is the current one-person bottleneck for all patches: your
review and merge of all patches into the notmuch/master branch.  This
would not necessarily be a problem if you could get to reviewing and
merging patches more frequently.  But as it is now, if there are no new
patches on notmuch/master for longer than the release period, there will
be nothing to package and upload.

This is *not* meant to be an indictment of you at all.  I know it's
incredibly hard to keep up with the incoming patch flow.  It takes a lot
of time and work to review every patch.  I also really like your
reviews.  They are incredibly thorough and insightful, and I always
learn from them.  Your intimate knowledge of the code base also means
that you can frequently come up with cleaner solutions to the proposed
patches (as with the reworked part handling).

However, the bottleneck presents a big problem when delays are
introduced.  We can't really do anything until you can get to the
review.  Furthermore, even if we do push ahead to put together a release
candidate branch (as we did with 0.6), if your review severely alters
patches early in that branch we have to do a lot of work to rework their
decedents (as we did with 0.6).  This leads to a lot of inefficiencies.

So we need to figure out a way to break the bottleneck.

I would really like to continue to get your review of patches.  I think
they're just too valuable.  So it would be really nice if one of the
solutions was a way to just "grease" the bottleneck, so to speak.  For
instance, if you could commit to reviewing just 1 patch series a week we
would be way ahead of where we have been.

Another thing that would help would be to delegate responsibility of
certain components to others, as you have with the python binding to
spaetz.  For instance, we have at least a couple of elisp experts
hanging around.  Maybe you could cede handling of all emacs patches to
someone like jkr or dme, and to felipe for vim, etc. (if they're willing
to take on those rolls).  That would help reduce your burden a bit.

We could also formalize some sort of tiered review system.  amdragon has
been doing a really good job of frequently providing good review of
patches on list.  I think that any proposed patch that gets a thumbs up

Re: When will we have our next release?

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth cwo...@cworth.org wrote:
 Frankly, I wouldn't mind doing strict time-based releases with something
 like the following:

Hi, Carl.  I think this is a fine idea, and we (not you) can definitely
run this process.  I'm quite sure that at least bremner and I can
completely handle this together, and I'm sure we can get others to help.

But the mechanics of the actual release are not the problem.  The
problem is the current one-person bottleneck for all patches: your
review and merge of all patches into the notmuch/master branch.  This
would not necessarily be a problem if you could get to reviewing and
merging patches more frequently.  But as it is now, if there are no new
patches on notmuch/master for longer than the release period, there will
be nothing to package and upload.

This is *not* meant to be an indictment of you at all.  I know it's
incredibly hard to keep up with the incoming patch flow.  It takes a lot
of time and work to review every patch.  I also really like your
reviews.  They are incredibly thorough and insightful, and I always
learn from them.  Your intimate knowledge of the code base also means
that you can frequently come up with cleaner solutions to the proposed
patches (as with the reworked part handling).

However, the bottleneck presents a big problem when delays are
introduced.  We can't really do anything until you can get to the
review.  Furthermore, even if we do push ahead to put together a release
candidate branch (as we did with 0.6), if your review severely alters
patches early in that branch we have to do a lot of work to rework their
decedents (as we did with 0.6).  This leads to a lot of inefficiencies.

So we need to figure out a way to break the bottleneck.

I would really like to continue to get your review of patches.  I think
they're just too valuable.  So it would be really nice if one of the
solutions was a way to just grease the bottleneck, so to speak.  For
instance, if you could commit to reviewing just 1 patch series a week we
would be way ahead of where we have been.

Another thing that would help would be to delegate responsibility of
certain components to others, as you have with the python binding to
spaetz.  For instance, we have at least a couple of elisp experts
hanging around.  Maybe you could cede handling of all emacs patches to
someone like jkr or dme, and to felipe for vim, etc. (if they're willing
to take on those rolls).  That would help reduce your burden a bit.

We could also formalize some sort of tiered review system.  amdragon has
been doing a really good job of frequently providing good review of
patches on list.  I think that any proposed patch that gets a thumbs up
From someone like amdragon should immediately be elevated in your queue,
or just applied out-right.  If the review of others explicitly helped
get patches merged faster, I'm quite sure it would encourage more folks
to submit their reviews as well.

I would love to hear any other ideas people have on this front.

Notmuch is an incredible project, with an absolutely incredible
development community.  It's an absolute joy to work on.  If we can just
grease the wheels a little bit to get releases out the door a little
quicker, I think we'll all be a lot happier.

jamie.


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

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth  wrote:
> Hopefully, someone will provide me with a good way to publish my queue
> soon, ("notmuch search --output=html" ?), and then communication like
> this will be a bit easier. ;-)

I've been thinking about this more and it really seems we need a way to
just share tags.  What if we had a way to export all the tags for a set
of messages as a notmuch dump file, that could just be piped into
notmuch to modify tags?  This would be a great way for lots of people to
keep tags synced on a set of messages.

The main difficulty (seems to me) would be the sharing of -tags.  You
wouldn't want the absence of a tag on a message in the tag file to mean
that the tag should be removed.  So we would need to represent both
+tags and -tags in the dump file [0].

It seems a little crazy, but would it be possible to store -tags in the
database somehow?

jamie.

[0] This would actually help with tags applied when the message is
indexed as well, like "signed" and "encrypted", since it would allow for
tagging messages that were indexed before the "signed"/"encrypted"
tagging was a feature.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth cwo...@cworth.org wrote:
 Hopefully, someone will provide me with a good way to publish my queue
 soon, (notmuch search --output=html ?), and then communication like
 this will be a bit easier. ;-)

I've been thinking about this more and it really seems we need a way to
just share tags.  What if we had a way to export all the tags for a set
of messages as a notmuch dump file, that could just be piped into
notmuch to modify tags?  This would be a great way for lots of people to
keep tags synced on a set of messages.

The main difficulty (seems to me) would be the sharing of -tags.  You
wouldn't want the absence of a tag on a message in the tag file to mean
that the tag should be removed.  So we would need to represent both
+tags and -tags in the dump file [0].

It seems a little crazy, but would it be possible to store -tags in the
database somehow?

jamie.

[0] This would actually help with tags applied when the message is
indexed as well, like signed and encrypted, since it would allow for
tagging messages that were indexed before the signed/encrypted
tagging was a feature.


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

improving message/rfc822 part handling

[Jameson Graef Rollins]

Here's the gmime bug about returning rfc822 messages as GMimeObjects:

https://bugzilla.gnome.org/show_bug.cgi?id=651964

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

release-candidate/0.6 redux

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth  wrote:
> From a quick rebase of your release-candidate branch and a comparison
> with what I have queued it looks like only the following commits are
> left on your branch and not in my email queue:
> 
> emacs: update notmuch-crypto-process-mime config variable documentation.

Hey, Carl.  This is actually a five-patch series that starts at:

 emacs: add notmuch-show-refresh-view function
  id:"1306627784-3401-1-git-send-email-jrollins at finestructure.net"

You should also look at the following two patch series to fix the
message/rfc822 part handling:

 Do not attept to output part raw if part is not GMimePart.
  id:"1307120466-4980-1-git-send-email-jrollins at finestructure.net"

 improving message/rfc822 part handling
  id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net"

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

improving message/rfc822 part handling

[Jameson Graef Rollins]

I forgot to mention that this patch series (well the last patch in
particular) supersedes the previous emacs rfc822 part handling patch I
sent in:

id:"1307034386-6107-1-git-send-email-jrollins at finestructure.net"

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH 5/5] emacs: Improve support for message/rfc822 parts.

[Jameson Graef Rollins]

The insert-part-message/rfc822 function is overhauled to properly
processes the new formatting of message/rfc822 parts.  The json output
for message parts now includes "headers" and "body" fields, which are
now parsed and output appropriately.
---
 emacs/notmuch-show.el |   21 +
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 7d848e3..0f1fe69 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -519,21 +519,26 @@ current buffer, if possible."
   t)

 (defun notmuch-show-insert-part-message/rfc822 (msg part content-type nth 
depth declared-type)
-  (let* ((message-part (plist-get part :content))
-(inner-parts (plist-get message-part :content)))
-(notmuch-show-insert-part-header nth declared-type content-type nil)
+  (notmuch-show-insert-part-header nth declared-type content-type nil)
+  (let* ((message (car (plist-get part :content)))
+(headers (plist-get message :headers))
+(body (car (plist-get message :body)))
+(start (point)))
+
 ;; Override `notmuch-message-headers' to force `From' to be
 ;; displayed.
 (let ((notmuch-message-headers '("From" "Subject" "To" "Cc" "Date")))
-  (notmuch-show-insert-headers (plist-get part :headers)))
+  (notmuch-show-insert-headers (plist-get message :headers)))
+
 ;; Blank line after headers to be compatible with the normal
 ;; message display.
 (insert "\n")

-;; Show all of the parts.
-(mapc (lambda (inner-part)
-   (notmuch-show-insert-bodypart msg inner-part depth))
- inner-parts))
+;; Show the body
+(notmuch-show-insert-bodypart msg body depth)
+
+(when notmuch-show-indent-multipart
+  (indent-rigidly start (point) 1)))
   t)

 (defun notmuch-show-insert-part-text/plain (msg part content-type nth depth 
declared-type)
-- 
1.7.4.4

[PATCH 4/5] Improve handling of message/rfc822 parts by adding a new header_message_part function to the formating structure.

[Jameson Graef Rollins]

This new function takes a GMimeMessage as input, and outputs the
formatted headers.  This allows for message/rfc822 parts to be
formatted on output in a similar way to full messages (see previous
patch that overhauls the multipart test for more info).
---
 notmuch-client.h |1 +
 notmuch-reply.c  |   31 ++-
 notmuch-show.c   |   88 ++---
 show-message.c   |   12 +++
 4 files changed, 119 insertions(+), 13 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index 63be337..b50cb38 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -63,6 +63,7 @@ typedef struct notmuch_show_format {
 const char *header_start;
 void (*header) (const void *ctx,
notmuch_message_t *message);
+void (*header_message_part) (GMimeMessage *message);
 const char *header_end;
 const char *body_start;
 void (*part_start) (GMimeObject *part,
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 514bbc6..a19eb19 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -25,12 +25,15 @@
 #include "gmime-filter-headers.h"

 static void
+reply_headers_message_part (GMimeMessage *message);
+
+static void
 reply_part_content (GMimeObject *part);

 static const notmuch_show_format_t format_reply = {
 "",
"", NULL,
-   "", NULL, "",
+   "", NULL, reply_headers_message_part, ">\n",
"",
NULL,
NULL,
@@ -63,6 +66,28 @@ show_reply_headers (GMimeMessage *message)
 }

 static void
+reply_headers_message_part (GMimeMessage *message)
+{
+InternetAddressList *recipients;
+const char *recipients_string;
+
+printf ("> From: %s\n", g_mime_message_get_sender (message));
+recipients = g_mime_message_get_recipients (message, 
GMIME_RECIPIENT_TYPE_TO);
+recipients_string = internet_address_list_to_string (recipients, 0);
+if (recipients_string)
+   printf ("> To: %s\n",
+   recipients_string);
+recipients = g_mime_message_get_recipients (message, 
GMIME_RECIPIENT_TYPE_CC);
+recipients_string = internet_address_list_to_string (recipients, 0);
+if (recipients_string)
+   printf ("> Cc: %s\n",
+   recipients_string);
+printf ("> Subject: %s\n", g_mime_message_get_subject (message));
+printf ("> Date: %s\n", g_mime_message_get_date_as_string (message));
+}
+
+
+static void
 reply_part_content (GMimeObject *part)
 {
 GMimeContentType *content_type = g_mime_object_get_content_type 
(GMIME_OBJECT (part));
@@ -95,6 +120,10 @@ reply_part_content (GMimeObject *part)
if (stream_stdout)
g_object_unref(stream_stdout);
 }
+else if (g_mime_content_type_is_type (content_type, "message", "rfc822"))
+{
+   /* Output nothing, since rfc822 subparts will be handled individually. 
*/
+}
 else
 {
if (disposition &&
diff --git a/notmuch-show.c b/notmuch-show.c
index 0e9d00d..6e2e560 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -29,6 +29,9 @@ format_headers_text (const void *ctx,
 notmuch_message_t *message);

 static void
+format_headers_message_part_text (GMimeMessage *message);
+
+static void
 format_part_start_text (GMimeObject *part,
int *part_count);

@@ -41,7 +44,7 @@ format_part_end_text (GMimeObject *part);
 static const notmuch_show_format_t format_text = {
 "",
"\fmessage{ ", format_message_text,
-   "\fheader{\n", format_headers_text, "\fheader}\n",
+   "\fheader{\n", format_headers_text, 
format_headers_message_part_text, "\fheader}\n",
"\fbody{\n",
format_part_start_text,
NULL,
@@ -63,6 +66,9 @@ format_headers_json (const void *ctx,
 notmuch_message_t *message);

 static void
+format_headers_message_part_json (GMimeMessage *message);
+
+static void
 format_part_start_json (unused (GMimeObject *part),
int *part_count);

@@ -81,7 +87,7 @@ format_part_end_json (GMimeObject *part);
 static const notmuch_show_format_t format_json = {
 "[",
"{", format_message_json,
-   ", \"headers\": {", format_headers_json, "}",
+   "\"headers\": {", format_headers_json, 
format_headers_message_part_json, "}",
", \"body\": [",
format_part_start_json,
format_part_encstatus_json,
@@ -102,7 +108,7 @@ format_message_mbox (const void *ctx,
 static const notmuch_show_format_t format_mbox = {
 "",
 "", format_message_mbox,
-"", NULL, "",
+"", NULL, NULL, "",
 "",
 NULL,
 NULL,
@@ -121,7 +127,7 @@ format_part_content_raw (GMimeObject *part);
 static const notmuch_show_format_t format_raw = {
 "",
"", NULL,
-   "", NULL, "",
+   "", NULL, format_headers_message_part_text, "\n",
 "",
 NULL,
 

[PATCH 3/5] test: overhaul multipart test to test for improved message/rfc822 handling

[Jameson Graef Rollins]

The main goal of this overhaul is to define how message/rfc822 parts
should be handled.  message/rfc822 parts should be output in a similar
fashion to the outer message, including some subset of the rfc822
headers.  The following decisions about formatting of message/rfc822
parts were made:

The format and content of message/rfc822 parts shall be as similar as
possible to that of full messages.  In particular, for formatted
outputs, the "content" of rfc822 part output should include "headers"
and "body" fields).

The "body" field shall include the body of the message.

The "headers" field shall include the following headers, since these
are the ones available from the GMimeMessage:

  "From"
  "To"
  "Cc"
  "Subject"
  "Date"

However, for the case of --format=raw the raw rfc822 should be output,
including all headers.

A subset of relevant headers shall be output in reply.

The test embedded rfc822 message is also modified to be itself
multipart, so we can more fully test how all sub parts of the message
part are output.
---
 test/multipart |  368 +++-
 1 files changed, 283 insertions(+), 85 deletions(-)

diff --git a/test/multipart b/test/multipart
index 67e04d9..95577dc 100755
--- a/test/multipart
+++ b/test/multipart
@@ -2,6 +2,29 @@
 test_description="output of multipart message"
 . ./test-lib.sh

+cat < embedded_message
+From: Carl Worth 
+To: cworth at cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
+Message-ID: <87liy5ap01.fsf at yoom.home.cworth.org>
+MIME-Version: 1.0
+Content-Type: multipart/alternative; boundary="==-=-=="
+
+--==-=-==
+Content-Type: text/html
+
+This is an embedded message, with a multipart/alternative part.
+
+--==-=-==
+Content-Type: text/plain
+
+This is an embedded message, with a multipart/alternative part.
+
+--==-=-==--
+EOF
+
 cat < ${MAIL_DIR}/multipart
 From: Carl Worth 
 To: cworth at cworth.org
@@ -20,17 +43,9 @@ Content-Type: multipart/mixed; boundary="=-=-="
 Content-Type: message/rfc822
 Content-Disposition: inline

-From: Carl Worth 
-To: cworth at cworth.org
-Subject: html message
-Date: Fri, 05 Jan 2001 15:42:57 +
-User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
-Message-ID: <87liy5ap01.fsf at yoom.home.cworth.org>
-MIME-Version: 1.0
-Content-Type: text/html
-
-This is an embedded message, with a single html part.
-
+EOF
+cat embedded_message >> ${MAIL_DIR}/multipart
+cat <> ${MAIL_DIR}/multipart
 --=-=-=
 Content-Disposition: attachment; filename=attachment

@@ -106,21 +121,34 @@ Date: Fri, 05 Jan 2001 15:43:57 +
 part{ ID: 1, Content-type: multipart/signed
 part{ ID: 2, Content-type: multipart/mixed
 part{ ID: 3, Content-type: message/rfc822
-part{ ID: 4, Content-type: text/html
+header{
+From: Carl Worth 
+To: cworth at cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+header}
+body{
+part{ ID: 4, Content-type: multipart/alternative
+part{ ID: 5, Content-type: text/html
 Non-text part: text/html
 part}
+part{ ID: 6, Content-type: text/plain
+This is an embedded message, with a multipart/alternative part.
+part}
+part}
+body}
 part}
-attachment{ ID: 5, Content-type: text/plain
+attachment{ ID: 7, Content-type: text/plain
 Attachment: attachment (text/plain)
 This is a text attachment.
 attachment}
-part{ ID: 6, Content-type: text/plain
+part{ ID: 8, Content-type: text/plain
 And this message is signed.

 -Carl
 part}
 part}
-part{ ID: 7, Content-type: application/pgp-signature
+part{ ID: 9, Content-type: application/pgp-signature
 Non-text part: application/pgp-signature
 part}
 part}
@@ -135,21 +163,34 @@ cat OU
 cat 

[PATCH 2/5] test: Fix date in test message in multipart test.

[Jameson Graef Rollins]

The test message date, "Tue, 05 Jan 2001 15:43:57 -", is not
actually a real date.  05 Jan 2001 was in fact a Friday, not a
Tuesday.  Date parsers (such as "date" in coreutils) will return "Fri"
as the day for this string, even if "Tue" is specified.

Also, the time zone "-" is actually always returned as "+", so
we change that here was well.

This will be relevant for later patches when we begin parsing rfc822
part headers, where gmime returns a parsed date string.

If we do want to test date parsing, we should do that in a separate
test.
---
 test/multipart |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/test/multipart b/test/multipart
index 9d6a9d1..67e04d9 100755
--- a/test/multipart
+++ b/test/multipart
@@ -6,7 +6,7 @@ cat < ${MAIL_DIR}/multipart
 From: Carl Worth 
 To: cworth at cworth.org
 Subject: Multipart message
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
 Message-ID: <87liy5ap00.fsf at yoom.home.cworth.org>
 MIME-Version: 1.0
@@ -23,7 +23,7 @@ Content-Disposition: inline
 From: Carl Worth 
 To: cworth at cworth.org
 Subject: html message
-Date: Tue, 05 Jan 2001 15:42:57 -
+Date: Fri, 05 Jan 2001 15:42:57 +
 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
 Message-ID: <87liy5ap01.fsf at yoom.home.cworth.org>
 MIME-Version: 1.0
@@ -61,7 +61,7 @@ cat < ${MAIL_DIR}/base64-part-with-crlf
 From: Carl Worth 
 To: cworth at cworth.org
 Subject: Test message with a BASE64 encoded binary containing CRLF pair
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
 Message-ID: 
 MIME-Version: 1.0
@@ -100,7 +100,7 @@ Carl Worth  (2001-01-05) (attachment 
inbox signed unread)
 Subject: Multipart message
 From: Carl Worth 
 To: cworth at cworth.org
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
 header}
 body{
 part{ ID: 1, Content-type: multipart/signed
@@ -235,7 +235,7 @@ test_expect_success \
 test_begin_subtest "--format=json --part=0, full message"
 output=$(notmuch show --format=json --part=0 'id:87liy5ap00.fsf at 
yoom.home.cworth.org')
 test_expect_equal "$output" \
-'{"id": "87liy5ap00.fsf at yoom.home.cworth.org", "match": true, "filename": 
"'"${MAIL_DIR}/multipart"'", "timestamp": 978709437, "date_relative": 
"2001-01-05", "tags": ["attachment","inbox","signed","unread"], "headers": 
{"Subject": "Multipart message", "From": "Carl Worth ", 
"To": "cworth at cworth.org", "Cc": "", "Bcc": "", "Date": "Tue, 05 Jan 2001 
15:43:57 -"}, "body": [{"id": 1, "content-type": "multipart/signed", 
"content": [{"id": 2, "content-type": "multipart/mixed", "content": [{"id": 3, 
"content-type": "message/rfc822", "content": [{"id": 4, "content-type": 
"text/html"}]}, {"id": 5, "content-type": "text/plain", "filename": 
"attachment", "content": "This is a text attachment.\n"}, {"id": 6, 
"content-type": "text/plain", "content": "And this message is 
signed.\n\n-Carl\n"}]}, {"id": 7, "content-type": 
"application/pgp-signature"}]}]}'
+'{"id": "87liy5ap00.fsf at yoom.home.cworth.org", "match": true, "filename": 
"'"${MAIL_DIR}/multipart"'", "timestamp": 978709437, "date_relative": 
"2001-01-05", "tags": ["attachment","inbox","signed","unread"], "headers": 
{"Subject": "Multipart message", "From": "Carl Worth ", 
"To": "cworth at cworth.org", "Cc": "", "Bcc": "", "Date": "Fri, 05 Jan 2001 
15:43:57 +"}, "body": [{"id": 1, "content-type": "multipart/signed", 
"content": [{"id": 2, "content-type": "multipart/mixed", "content": [{"id": 3, 
"content-type": "message/rfc822", "content": [{"id": 4, "content-type": 
"text/html"}]}, {"id": 5, "content-type": "text/plain", "filename": 
"attachment", "content": "This is a text attachment.\n"}, {"id": 6, 
"content-type": "text/plain", "content": "And this message is 
signed.\n\n-Carl\n"}]}, {"id": 7, "content-type": 
"application/pgp-signature"}]}]}'

 test_begin_subtest "--format=json --part=1, message body"
 output=$(notmuch show --format=json --part=1 'id:87liy5ap00.fsf at 
yoom.home.cworth.org')
@@ -385,7 +385,7 @@ To: Carl Worth , cworth at cworth.org
 In-Reply-To: <87liy5ap00.fsf at yoom.home.cworth.org>
 References: <87liy5ap00.fsf at yoom.home.cworth.org>

-On Tue, 05 Jan 2001 15:43:57 -, Carl Worth  wrote:
+On Fri, 05 Jan 2001 15:43:57 +, Carl Worth  wrote:
 Non-text part: multipart/signed
 Non-text part: multipart/mixed
 Non-text part: message/rfc822
-- 
1.7.4.4

[PATCH 1/5] test: some small fixes to multipart test

[Jameson Graef Rollins]

There were two "--format=text --part=0" tests.  One of them was
supposed to be a test for "--format=text --part=1".

There were also two errant "test_expect_equal_file OUTPUT EXPECTED"
lines, that are removed here.
---
 test/multipart |   17 ++---
 1 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/test/multipart b/test/multipart
index 0879696..9d6a9d1 100755
--- a/test/multipart
+++ b/test/multipart
@@ -129,18 +129,9 @@ Non-text part: application/pgp-signature
 EOF
 test_expect_equal_file OUTPUT EXPECTED

-test_begin_subtest "--format=text --part=0, full message"
-notmuch show --format=text --part=0 'id:87liy5ap00.fsf at 
yoom.home.cworth.org' >OUTPUT
+test_begin_subtest "--format=text --part=1, message body"
+notmuch show --format=text --part=1 'id:87liy5ap00.fsf at 
yoom.home.cworth.org' >OUTPUT
 cat 

improving message/rfc822 part handling

[Jameson Graef Rollins]

So the following patch series is my attempt to improve handling of
message/rfc822 parts.  The first couple of patches fix/overhaul the
multipart test, and the last two improve the message/rfc822 part
output and emacs handling, respectively.

The fix outputs the rfc822 message in a format similar to that of the
outer message, including "headers" and "body" fields.

What this doesn't yet address is the raw output of message/rfc822
parts.  The raw output of message/rfc822 parts /should/ be the full
raw message.  However, I have not yet figured out how to do that yet,
so the multipart test for raw message/rfc822 parts is not yet fixed.

The problem is really gmime's handling of message parts.  There
doesn't seem to be a gmime function that will return the message part
as a GMimeObject.  This means that we can't access all the message
headers, or the messages sub parts as mime objects.  There may be a
way to hack around gmime's limitations, but I haven't figured it out
yet.  If someone else wants to take a crack at it, that would be
great.  In the mean time, I'm opening a bug report with gmime to
request a function to return the rfc822 part as a GMimeObject.

jamie.

[PATCH 4/5] Improve handling of message/rfc822 parts by adding a new header_message_part function to the formating structure.

[Jameson Graef Rollins]

This new function takes a GMimeMessage as input, and outputs the
formatted headers.  This allows for message/rfc822 parts to be
formatted on output in a similar way to full messages (see previous
patch that overhauls the multipart test for more info).
---
 notmuch-client.h |1 +
 notmuch-reply.c  |   31 ++-
 notmuch-show.c   |   88 ++---
 show-message.c   |   12 +++
 4 files changed, 119 insertions(+), 13 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index 63be337..b50cb38 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -63,6 +63,7 @@ typedef struct notmuch_show_format {
 const char *header_start;
 void (*header) (const void *ctx,
notmuch_message_t *message);
+void (*header_message_part) (GMimeMessage *message);
 const char *header_end;
 const char *body_start;
 void (*part_start) (GMimeObject *part,
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 514bbc6..a19eb19 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -25,12 +25,15 @@
 #include gmime-filter-headers.h
 
 static void
+reply_headers_message_part (GMimeMessage *message);
+
+static void
 reply_part_content (GMimeObject *part);
 
 static const notmuch_show_format_t format_reply = {
 ,
, NULL,
-   , NULL, ,
+   , NULL, reply_headers_message_part, \n,
,
NULL,
NULL,
@@ -63,6 +66,28 @@ show_reply_headers (GMimeMessage *message)
 }
 
 static void
+reply_headers_message_part (GMimeMessage *message)
+{
+InternetAddressList *recipients;
+const char *recipients_string;
+
+printf ( From: %s\n, g_mime_message_get_sender (message));
+recipients = g_mime_message_get_recipients (message, 
GMIME_RECIPIENT_TYPE_TO);
+recipients_string = internet_address_list_to_string (recipients, 0);
+if (recipients_string)
+   printf ( To: %s\n,
+   recipients_string);
+recipients = g_mime_message_get_recipients (message, 
GMIME_RECIPIENT_TYPE_CC);
+recipients_string = internet_address_list_to_string (recipients, 0);
+if (recipients_string)
+   printf ( Cc: %s\n,
+   recipients_string);
+printf ( Subject: %s\n, g_mime_message_get_subject (message));
+printf ( Date: %s\n, g_mime_message_get_date_as_string (message));
+}
+
+
+static void
 reply_part_content (GMimeObject *part)
 {
 GMimeContentType *content_type = g_mime_object_get_content_type 
(GMIME_OBJECT (part));
@@ -95,6 +120,10 @@ reply_part_content (GMimeObject *part)
if (stream_stdout)
g_object_unref(stream_stdout);
 }
+else if (g_mime_content_type_is_type (content_type, message, rfc822))
+{
+   /* Output nothing, since rfc822 subparts will be handled individually. 
*/
+}
 else
 {
if (disposition 
diff --git a/notmuch-show.c b/notmuch-show.c
index 0e9d00d..6e2e560 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -29,6 +29,9 @@ format_headers_text (const void *ctx,
 notmuch_message_t *message);
 
 static void
+format_headers_message_part_text (GMimeMessage *message);
+
+static void
 format_part_start_text (GMimeObject *part,
int *part_count);
 
@@ -41,7 +44,7 @@ format_part_end_text (GMimeObject *part);
 static const notmuch_show_format_t format_text = {
 ,
\fmessage{ , format_message_text,
-   \fheader{\n, format_headers_text, \fheader}\n,
+   \fheader{\n, format_headers_text, 
format_headers_message_part_text, \fheader}\n,
\fbody{\n,
format_part_start_text,
NULL,
@@ -63,6 +66,9 @@ format_headers_json (const void *ctx,
 notmuch_message_t *message);
 
 static void
+format_headers_message_part_json (GMimeMessage *message);
+
+static void
 format_part_start_json (unused (GMimeObject *part),
int *part_count);
 
@@ -81,7 +87,7 @@ format_part_end_json (GMimeObject *part);
 static const notmuch_show_format_t format_json = {
 [,
{, format_message_json,
-   , \headers\: {, format_headers_json, },
+   \headers\: {, format_headers_json, 
format_headers_message_part_json, },
, \body\: [,
format_part_start_json,
format_part_encstatus_json,
@@ -102,7 +108,7 @@ format_message_mbox (const void *ctx,
 static const notmuch_show_format_t format_mbox = {
 ,
 , format_message_mbox,
-, NULL, ,
+, NULL, NULL, ,
 ,
 NULL,
 NULL,
@@ -121,7 +127,7 @@ format_part_content_raw (GMimeObject *part);
 static const notmuch_show_format_t format_raw = {
 ,
, NULL,
-   , NULL, ,
+   , NULL, format_headers_message_part_text, \n,
 ,
 NULL,
 NULL,
@@ -216,7 +222,7 @@ format_message_json (const void *ctx, notmuch_message_t 
*message, 

[PATCH 5/5] emacs: Improve support for message/rfc822 parts.

[Jameson Graef Rollins]

The insert-part-message/rfc822 function is overhauled to properly
processes the new formatting of message/rfc822 parts.  The json output
for message parts now includes headers and body fields, which are
now parsed and output appropriately.
---
 emacs/notmuch-show.el |   21 +
 1 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 7d848e3..0f1fe69 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -519,21 +519,26 @@ current buffer, if possible.
   t)
 
 (defun notmuch-show-insert-part-message/rfc822 (msg part content-type nth 
depth declared-type)
-  (let* ((message-part (plist-get part :content))
-(inner-parts (plist-get message-part :content)))
-(notmuch-show-insert-part-header nth declared-type content-type nil)
+  (notmuch-show-insert-part-header nth declared-type content-type nil)
+  (let* ((message (car (plist-get part :content)))
+(headers (plist-get message :headers))
+(body (car (plist-get message :body)))
+(start (point)))
+
 ;; Override `notmuch-message-headers' to force `From' to be
 ;; displayed.
 (let ((notmuch-message-headers '(From Subject To Cc Date)))
-  (notmuch-show-insert-headers (plist-get part :headers)))
+  (notmuch-show-insert-headers (plist-get message :headers)))
+
 ;; Blank line after headers to be compatible with the normal
 ;; message display.
 (insert \n)
 
-;; Show all of the parts.
-(mapc (lambda (inner-part)
-   (notmuch-show-insert-bodypart msg inner-part depth))
- inner-parts))
+;; Show the body
+(notmuch-show-insert-bodypart msg body depth)
+
+(when notmuch-show-indent-multipart
+  (indent-rigidly start (point) 1)))
   t)
 
 (defun notmuch-show-insert-part-text/plain (msg part content-type nth depth 
declared-type)
-- 
1.7.4.4

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

[PATCH 2/5] test: Fix date in test message in multipart test.

[Jameson Graef Rollins]

The test message date, Tue, 05 Jan 2001 15:43:57 -, is not
actually a real date.  05 Jan 2001 was in fact a Friday, not a
Tuesday.  Date parsers (such as date in coreutils) will return Fri
as the day for this string, even if Tue is specified.

Also, the time zone - is actually always returned as +, so
we change that here was well.

This will be relevant for later patches when we begin parsing rfc822
part headers, where gmime returns a parsed date string.

If we do want to test date parsing, we should do that in a separate
test.
---
 test/multipart |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/test/multipart b/test/multipart
index 9d6a9d1..67e04d9 100755
--- a/test/multipart
+++ b/test/multipart
@@ -6,7 +6,7 @@ cat EOF  ${MAIL_DIR}/multipart
 From: Carl Worth cwo...@cworth.org
 To: cwo...@cworth.org
 Subject: Multipart message
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
 Message-ID: 87liy5ap00@yoom.home.cworth.org
 MIME-Version: 1.0
@@ -23,7 +23,7 @@ Content-Disposition: inline
 From: Carl Worth cwo...@cworth.org
 To: cwo...@cworth.org
 Subject: html message
-Date: Tue, 05 Jan 2001 15:42:57 -
+Date: Fri, 05 Jan 2001 15:42:57 +
 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
 Message-ID: 87liy5ap01@yoom.home.cworth.org
 MIME-Version: 1.0
@@ -61,7 +61,7 @@ cat EOF  ${MAIL_DIR}/base64-part-with-crlf
 From: Carl Worth cwo...@cworth.org
 To: cwo...@cworth.org
 Subject: Test message with a BASE64 encoded binary containing CRLF pair
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
 Message-ID: base64-part-with-crlf
 MIME-Version: 1.0
@@ -100,7 +100,7 @@ Carl Worth cwo...@cworth.org (2001-01-05) (attachment 
inbox signed unread)
 Subject: Multipart message
 From: Carl Worth cwo...@cworth.org
 To: cwo...@cworth.org
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
 header}
 body{
 part{ ID: 1, Content-type: multipart/signed
@@ -235,7 +235,7 @@ test_expect_success \
 test_begin_subtest --format=json --part=0, full message
 output=$(notmuch show --format=json --part=0 
'id:87liy5ap00@yoom.home.cworth.org')
 test_expect_equal $output \
-'{id: 87liy5ap00@yoom.home.cworth.org, match: true, filename: 
'${MAIL_DIR}/multipart', timestamp: 978709437, date_relative: 
2001-01-05, tags: [attachment,inbox,signed,unread], headers: 
{Subject: Multipart message, From: Carl Worth cwo...@cworth.org, 
To: cwo...@cworth.org, Cc: , Bcc: , Date: Tue, 05 Jan 2001 
15:43:57 -}, body: [{id: 1, content-type: multipart/signed, 
content: [{id: 2, content-type: multipart/mixed, content: [{id: 3, 
content-type: message/rfc822, content: [{id: 4, content-type: 
text/html}]}, {id: 5, content-type: text/plain, filename: 
attachment, content: This is a text attachment.\n}, {id: 6, 
content-type: text/plain, content: And this message is 
signed.\n\n-Carl\n}]}, {id: 7, content-type: 
application/pgp-signature}]}]}'
+'{id: 87liy5ap00@yoom.home.cworth.org, match: true, filename: 
'${MAIL_DIR}/multipart', timestamp: 978709437, date_relative: 
2001-01-05, tags: [attachment,inbox,signed,unread], headers: 
{Subject: Multipart message, From: Carl Worth cwo...@cworth.org, 
To: cwo...@cworth.org, Cc: , Bcc: , Date: Fri, 05 Jan 2001 
15:43:57 +}, body: [{id: 1, content-type: multipart/signed, 
content: [{id: 2, content-type: multipart/mixed, content: [{id: 3, 
content-type: message/rfc822, content: [{id: 4, content-type: 
text/html}]}, {id: 5, content-type: text/plain, filename: 
attachment, content: This is a text attachment.\n}, {id: 6, 
content-type: text/plain, content: And this message is 
signed.\n\n-Carl\n}]}, {id: 7, content-type: 
application/pgp-signature}]}]}'
 
 test_begin_subtest --format=json --part=1, message body
 output=$(notmuch show --format=json --part=1 
'id:87liy5ap00@yoom.home.cworth.org')
@@ -385,7 +385,7 @@ To: Carl Worth cwo...@cworth.org, cwo...@cworth.org
 In-Reply-To: 87liy5ap00@yoom.home.cworth.org
 References: 87liy5ap00@yoom.home.cworth.org
 
-On Tue, 05 Jan 2001 15:43:57 -, Carl Worth cwo...@cworth.org wrote:
+On Fri, 05 Jan 2001 15:43:57 +, Carl Worth cwo...@cworth.org wrote:
 Non-text part: multipart/signed
 Non-text part: multipart/mixed
 Non-text part: message/rfc822
-- 
1.7.4.4

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

improving message/rfc822 part handling

[Jameson Graef Rollins]

So the following patch series is my attempt to improve handling of
message/rfc822 parts.  The first couple of patches fix/overhaul the
multipart test, and the last two improve the message/rfc822 part
output and emacs handling, respectively.

The fix outputs the rfc822 message in a format similar to that of the
outer message, including headers and body fields.

What this doesn't yet address is the raw output of message/rfc822
parts.  The raw output of message/rfc822 parts /should/ be the full
raw message.  However, I have not yet figured out how to do that yet,
so the multipart test for raw message/rfc822 parts is not yet fixed.

The problem is really gmime's handling of message parts.  There
doesn't seem to be a gmime function that will return the message part
as a GMimeObject.  This means that we can't access all the message
headers, or the messages sub parts as mime objects.  There may be a
way to hack around gmime's limitations, but I haven't figured it out
yet.  If someone else wants to take a crack at it, that would be
great.  In the mean time, I'm opening a bug report with gmime to
request a function to return the rfc822 part as a GMimeObject.

jamie.

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

[PATCH 1/5] test: some small fixes to multipart test

[Jameson Graef Rollins]

There were two --format=text --part=0 tests.  One of them was
supposed to be a test for --format=text --part=1.

There were also two errant test_expect_equal_file OUTPUT EXPECTED
lines, that are removed here.
---
 test/multipart |   17 ++---
 1 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/test/multipart b/test/multipart
index 0879696..9d6a9d1 100755
--- a/test/multipart
+++ b/test/multipart
@@ -129,18 +129,9 @@ Non-text part: application/pgp-signature
 EOF
 test_expect_equal_file OUTPUT EXPECTED
 
-test_begin_subtest --format=text --part=0, full message
-notmuch show --format=text --part=0 'id:87liy5ap00@yoom.home.cworth.org' 
OUTPUT
+test_begin_subtest --format=text --part=1, message body
+notmuch show --format=text --part=1 'id:87liy5ap00@yoom.home.cworth.org' 
OUTPUT
 cat EOF EXPECTED
-message{ id:87liy5ap00@yoom.home.cworth.org depth:0 match:1 
filename:${MAIL_DIR}/multipart
-header{
-Carl Worth cwo...@cworth.org (2001-01-05) (attachment inbox signed unread)
-Subject: Multipart message
-From: Carl Worth cwo...@cworth.org
-To: cwo...@cworth.org
-Date: Tue, 05 Jan 2001 15:43:57 -
-header}
-body{
 part{ ID: 1, Content-type: multipart/signed
 part{ ID: 2, Content-type: multipart/mixed
 part{ ID: 3, Content-type: message/rfc822
@@ -162,8 +153,6 @@ And this message is signed.
 Non-text part: application/pgp-signature
 part}
 part}
-body}
-message}
 EOF
 test_expect_equal_file OUTPUT EXPECTED
 
@@ -257,13 +246,11 @@ test_begin_subtest --format=json --part=2, 
multipart/mixed
 output=$(notmuch show --format=json --part=2 
'id:87liy5ap00@yoom.home.cworth.org')
 test_expect_equal $output \
 '{id: 2, content-type: multipart/mixed, content: [{id: 3, 
content-type: message/rfc822, content: [{id: 4, content-type: 
text/html}]}, {id: 5, content-type: text/plain, filename: 
attachment, content: This is a text attachment.\n}, {id: 6, 
content-type: text/plain, content: And this message is 
signed.\n\n-Carl\n}]}'
-test_expect_equal_file OUTPUT EXPECTED
 
 test_begin_subtest --format=json --part=3, rfc822 multipart
 output=$(notmuch show --format=json --part=3 
'id:87liy5ap00@yoom.home.cworth.org')
 test_expect_equal $output \
 '{id: 3, content-type: message/rfc822, content: [{id: 4, 
content-type: text/html}]}'
-test_expect_equal_file OUTPUT EXPECTED
 
 test_begin_subtest --format=json --part=4, html part
 output=$(notmuch show --format=json --part=4 
'id:87liy5ap00@yoom.home.cworth.org')
-- 
1.7.4.4

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

[PATCH 3/5] test: overhaul multipart test to test for improved message/rfc822 handling

[Jameson Graef Rollins]

The main goal of this overhaul is to define how message/rfc822 parts
should be handled.  message/rfc822 parts should be output in a similar
fashion to the outer message, including some subset of the rfc822
headers.  The following decisions about formatting of message/rfc822
parts were made:

The format and content of message/rfc822 parts shall be as similar as
possible to that of full messages.  In particular, for formatted
outputs, the content of rfc822 part output should include headers
and body fields).

The body field shall include the body of the message.

The headers field shall include the following headers, since these
are the ones available from the GMimeMessage:

  From
  To
  Cc
  Subject
  Date

However, for the case of --format=raw the raw rfc822 should be output,
including all headers.

A subset of relevant headers shall be output in reply.

The test embedded rfc822 message is also modified to be itself
multipart, so we can more fully test how all sub parts of the message
part are output.
---
 test/multipart |  368 +++-
 1 files changed, 283 insertions(+), 85 deletions(-)

diff --git a/test/multipart b/test/multipart
index 67e04d9..95577dc 100755
--- a/test/multipart
+++ b/test/multipart
@@ -2,6 +2,29 @@
 test_description=output of multipart message
 . ./test-lib.sh
 
+cat EOF  embedded_message
+From: Carl Worth cwo...@cworth.org
+To: cwo...@cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
+Message-ID: 87liy5ap01@yoom.home.cworth.org
+MIME-Version: 1.0
+Content-Type: multipart/alternative; boundary===-=-==
+
+--==-=-==
+Content-Type: text/html
+
+pThis is an embedded message, with a multipart/alternative part./p
+
+--==-=-==
+Content-Type: text/plain
+
+This is an embedded message, with a multipart/alternative part.
+
+--==-=-==--
+EOF
+
 cat EOF  ${MAIL_DIR}/multipart
 From: Carl Worth cwo...@cworth.org
 To: cwo...@cworth.org
@@ -20,17 +43,9 @@ Content-Type: multipart/mixed; boundary==-=-=
 Content-Type: message/rfc822
 Content-Disposition: inline
 
-From: Carl Worth cwo...@cworth.org
-To: cwo...@cworth.org
-Subject: html message
-Date: Fri, 05 Jan 2001 15:42:57 +
-User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 
(i486-pc-linux-gnu)
-Message-ID: 87liy5ap01@yoom.home.cworth.org
-MIME-Version: 1.0
-Content-Type: text/html
-
-pThis is an embedded message, with a single html part./p
-
+EOF
+cat embedded_message  ${MAIL_DIR}/multipart
+cat EOF  ${MAIL_DIR}/multipart
 --=-=-=
 Content-Disposition: attachment; filename=attachment
 
@@ -106,21 +121,34 @@ Date: Fri, 05 Jan 2001 15:43:57 +
 part{ ID: 1, Content-type: multipart/signed
 part{ ID: 2, Content-type: multipart/mixed
 part{ ID: 3, Content-type: message/rfc822
-part{ ID: 4, Content-type: text/html
+header{
+From: Carl Worth cwo...@cworth.org
+To: cwo...@cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+header}
+body{
+part{ ID: 4, Content-type: multipart/alternative
+part{ ID: 5, Content-type: text/html
 Non-text part: text/html
 part}
+part{ ID: 6, Content-type: text/plain
+This is an embedded message, with a multipart/alternative part.
+part}
+part}
+body}
 part}
-attachment{ ID: 5, Content-type: text/plain
+attachment{ ID: 7, Content-type: text/plain
 Attachment: attachment (text/plain)
 This is a text attachment.
 attachment}
-part{ ID: 6, Content-type: text/plain
+part{ ID: 8, Content-type: text/plain
 And this message is signed.
 
 -Carl
 part}
 part}
-part{ ID: 7, Content-type: application/pgp-signature
+part{ ID: 9, Content-type: application/pgp-signature
 Non-text part: application/pgp-signature
 part}
 part}
@@ -135,21 +163,34 @@ cat EOF EXPECTED
 part{ ID: 1, Content-type: multipart/signed
 part{ ID: 2, Content-type: multipart/mixed
 part{ ID: 3, Content-type: message/rfc822
-part{ ID: 4, Content-type: text/html
+header{
+From: Carl Worth cwo...@cworth.org
+To: cwo...@cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+header}
+body{
+part{ ID: 4, Content-type: multipart/alternative
+part{ ID: 5, Content-type: text/html
 Non-text part: text/html
 part}
+part{ ID: 6, Content-type: text/plain
+This is an embedded message, with a multipart/alternative part.
+part}
 part}
-attachment{ ID: 5, Content-type: text/plain
+body}
+part}
+attachment{ ID: 7, Content-type: text/plain
 Attachment: attachment (text/plain)
 This is a text attachment.
 attachment}
-part{ ID: 6, Content-type: text/plain
+part{ ID: 8, Content-type: text/plain
 And this message is signed.
 
 -Carl
 part}
 part}
-part{ ID: 7, Content-type: application/pgp-signature
+part{ ID: 9, Content-type: application/pgp-signature
 Non-text part: application/pgp-signature
 part}
 part}
@@ -161,15 +202,28 @@ notmuch show --format=text --part=2 
'id:87liy5ap00@yoom.home.cworth.org' OU
 cat EOF 

Re: improving message/rfc822 part handling

[Jameson Graef Rollins]

I forgot to mention that this patch series (well the last patch in
particular) supersedes the previous emacs rfc822 part handling patch I
sent in:

id:1307034386-6107-1-git-send-email-jroll...@finestructure.net

jamie.


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

Re: release-candidate/0.6 redux

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth cwo...@cworth.org wrote:
 From a quick rebase of your release-candidate branch and a comparison
 with what I have queued it looks like only the following commits are
 left on your branch and not in my email queue:
 
 emacs: update notmuch-crypto-process-mime config variable documentation.

Hey, Carl.  This is actually a five-patch series that starts at:

 emacs: add notmuch-show-refresh-view function
  id:1306627784-3401-1-git-send-email-jroll...@finestructure.net

You should also look at the following two patch series to fix the
message/rfc822 part handling:

 Do not attept to output part raw if part is not GMimePart.
  id:1307120466-4980-1-git-send-email-jroll...@finestructure.net

 improving message/rfc822 part handling
  id:1307320169-29905-1-git-send-email-jroll...@finestructure.net

jamie.


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

Re: improving message/rfc822 part handling

[Jameson Graef Rollins]

Here's the gmime bug about returning rfc822 messages as GMimeObjects:

https://bugzilla.gnome.org/show_bug.cgi?id=651964

jamie.


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

[PATCH 25/25] Fix stdout stream grabbing in format_part_content_text

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 15:38:29 -0700, Carl Worth  wrote:
> commit d5b4d950245605b84c56ce991fa3c59a073a70e5
> Author: Jameson Graef Rollins 
> Date:   Sat May 28 14:52:00 2011 -0700
> 
> show: Avoid inadvertently closing stdout
> 
> GMime has a nasty habit of taking ownership by default of any FILE*
> handed to it va g_mime_stream_file_new. Specifically it will close the
> FILE* when the stream is destroyed---even though GMime didn't open the
> file itself.
> 
> To avoid this bad behavior, we have to carefully set_owner(FALSE)
> after calling g_mime_stream_file_new. In the format_part_content_text
> function, since commit d92146d3a6809f8ad940302af49cd99a0820665e we've
> been calling g_mime_stream_file_new unconditionally, but only calling
> g_mime_stream_file_set_owner(FALSE) conditionally.
> 
> This led to the FILE* being closed early when notmuch show output was
> redirected to a file.
> 
> Fixing this fixes the test-suite cases that broke with the previous
> commit, (which added redirected "notmuch show" calls to the test suite
> to expose this bug).
> 
> Edited-by: Carl Worth  with a new commit message to
> explain the bug and fix.

Now I sound like I know what I'm talking about!  Thanks, Carl.

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/20110603/ee1f143f/attachment-0001.pgp>

[PATCH 25/25] Fix stdout stream grabbing in format_part_content_text

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth  wrote:
> Otherwise, the patches up to this point in the thread have all either
> been pushed or I've asked for some additional information (perhaps
> that's just this patch and the "old style fcc dirs" patch?).

Great!  That's really great news, Carl.  Thank you very much.  I think
at this point the only thing we need for 0.6 are:

* Austin's atomicity patches
* maybe fix the frc822 handling issue

Can we set a target date for 0.6 release?  So we'll all start feeling
really bad if we miss it?

> I'm actually a bit surprised to see myself preferring patches in
> email. When Linus first wrote git, I couldn't understand why the Linux
> community kept to such a consistent culture of sending patches via
> email. It seemed so backwards to do these awkward machinations (git
> format-patch, git send-email, SMTP, MUA, git am), and risk all the
> problems of email clients corrupting patches, etc.?especially when git
> has such clean mechanisms for reliably moving patches around (git push,
> git pull).

Yeah, I'm with you that I'm surprised by liking this method as well.  I
think it only really works once most of the bulk of things are already
working, but for bug fixes and feature additions it really works well.
It's nice to have comments for patches on list.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH 25/25] Fix stdout stream grabbing in format_part_content_text

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth  wrote:
> On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins  finestructure.net> wrote:
> > The declaration of the GMimeStream pointer to stdout in
> > format_part_content_text was somehow preventing subsequent printf
> > calls from outputting to stdout if the output was redirected to a
> > file.  Scoping the declaration to the actual use of the stream pointer
> > works around this problem.
> 
> This commit message sounds like we don't actually understand the problem
> being fixed here.

Well actually it's only meant to sound like the committer doesn't
understand the problem!

> I'd like to investigate this more. Perhaps with a test case?

The current tests are how I found the problem!  Without this patch at
least the multipart tests will fail.  I don't see how another test will
add anything.

Carl, if you (or anyone else) understands what the issue is, then please
go ahead and modify the commit message.  I don't understand things
enough myself to do any better.  Clearly there is some strange
interaction with things that try to use stdout after
g_mime_stream_file_new() has already grabbed it.

I really wouldn't block on this, though, since the patch does fix an
actual bug.

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/20110603/c9d3cac7/attachment.pgp>

[PATCH] Do not attept to output part raw if part is not GMimePart.

[Jameson Graef Rollins]

This was a minor oversite in checking of part type when outputing
content raw.  This was causing gmime was to throw an exception to
stderr.

Unfortunately the gmime exception was not being caught by notmuch, or
the test suite.  I'm not sure if notmuch should have done anything in
this case, but certainly the test suite should be capable of detecting
that something unexpected was output to stderr.
---
This is a cleaner version of this patch.

 notmuch-show.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index 9267d02..59f7078 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -644,6 +644,9 @@ format_part_end_json (GMimeObject *part)
 static void
 format_part_content_raw (GMimeObject *part)
 {
+if (! GMIME_IS_PART (part))
+   return;
+
 GMimeStream *stream_stdout;
 GMimeStream *stream_filter = NULL;
 GMimeDataWrapper *wrapper;
-- 
1.7.4.4

Re: [PATCH 25/25] Fix stdout stream grabbing in format_part_content_text

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth cwo...@cworth.org wrote:
 On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
  The declaration of the GMimeStream pointer to stdout in
  format_part_content_text was somehow preventing subsequent printf
  calls from outputting to stdout if the output was redirected to a
  file.  Scoping the declaration to the actual use of the stream pointer
  works around this problem.
 
 This commit message sounds like we don't actually understand the problem
 being fixed here.

Well actually it's only meant to sound like the committer doesn't
understand the problem!

 I'd like to investigate this more. Perhaps with a test case?

The current tests are how I found the problem!  Without this patch at
least the multipart tests will fail.  I don't see how another test will
add anything.

Carl, if you (or anyone else) understands what the issue is, then please
go ahead and modify the commit message.  I don't understand things
enough myself to do any better.  Clearly there is some strange
interaction with things that try to use stdout after
g_mime_stream_file_new() has already grabbed it.

I really wouldn't block on this, though, since the patch does fix an
actual bug.

jamie.


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

Re: [PATCH 25/25] Fix stdout stream grabbing in format_part_content_text

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth cwo...@cworth.org wrote:
 Otherwise, the patches up to this point in the thread have all either
 been pushed or I've asked for some additional information (perhaps
 that's just this patch and the old style fcc dirs patch?).

Great!  That's really great news, Carl.  Thank you very much.  I think
at this point the only thing we need for 0.6 are:

* Austin's atomicity patches
* maybe fix the frc822 handling issue

Can we set a target date for 0.6 release?  So we'll all start feeling
really bad if we miss it?

 I'm actually a bit surprised to see myself preferring patches in
 email. When Linus first wrote git, I couldn't understand why the Linux
 community kept to such a consistent culture of sending patches via
 email. It seemed so backwards to do these awkward machinations (git
 format-patch, git send-email, SMTP, MUA, git am), and risk all the
 problems of email clients corrupting patches, etc.—especially when git
 has such clean mechanisms for reliably moving patches around (git push,
 git pull).

Yeah, I'm with you that I'm surprised by liking this method as well.  I
think it only really works once most of the bulk of things are already
working, but for bug fixes and feature additions it really works well.
It's nice to have comments for patches on list.

jamie.


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

Re: [PATCH 25/25] Fix stdout stream grabbing in format_part_content_text

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 15:38:29 -0700, Carl Worth cwo...@cworth.org wrote:
 commit d5b4d950245605b84c56ce991fa3c59a073a70e5
 Author: Jameson Graef Rollins jroll...@finestructure.net
 Date:   Sat May 28 14:52:00 2011 -0700
 
 show: Avoid inadvertently closing stdout
 
 GMime has a nasty habit of taking ownership by default of any FILE*
 handed to it va g_mime_stream_file_new. Specifically it will close the
 FILE* when the stream is destroyed---even though GMime didn't open the
 file itself.
 
 To avoid this bad behavior, we have to carefully set_owner(FALSE)
 after calling g_mime_stream_file_new. In the format_part_content_text
 function, since commit d92146d3a6809f8ad940302af49cd99a0820665e we've
 been calling g_mime_stream_file_new unconditionally, but only calling
 g_mime_stream_file_set_owner(FALSE) conditionally.
 
 This led to the FILE* being closed early when notmuch show output was
 redirected to a file.
 
 Fixing this fixes the test-suite cases that broke with the previous
 commit, (which added redirected notmuch show calls to the test suite
 to expose this bug).
 
 Edited-by: Carl Worth cwo...@cworth.org with a new commit message to
 explain the bug and fix.

Now I sound like I know what I'm talking about!  Thanks, Carl.

jamie.


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

Decryption fails

[Jameson Graef Rollins]

On Thu, 02 Jun 2011 18:49:22 +0200, Felix Geller  wrote:
> Jeff replied and sent me a working patch :) Not sure yet how he prefers
> to publish the patch, but the problem is fixed.

That's great!  What did Jeff say exactly?  Is the patch to gmime 2.4?
Did he mention that he was including them in upstream, hopefully in the
next release?

> > Interestingly, I see the following message in your crypto test output:
> > 
> >   Error: search term did not match precisely one message.
> > 
> > which seems to indicate that the desired message wasn't actually
> > delivered properly, contrary to what the emacs delivery tests are
> > stating.  Not sure how that could be related, though, since it looks
> > like the trace that you show above definitely looks like gmime caught in
> > a poll loop.
> 
> Just ran the tests with a "fixed" poll function and it seems that many
> problems remain. Don't have the time at the moment to take a closer
> look, but I attached the output.

Those test failures look very strange to me.  There are a bunch of 'n's
being output after the commas in the json output.  Felix, are you sure
you haven't modified your source at all?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

problems with message/rfc822 parts

[Jameson Graef Rollins]

Hey, folks.  I've been noticing a couple of issues with message/rfc822
part handling in recent builds of notmuch/master.  They are rooted in
the new part handling rework that was done recently.  I just want to
mention them here, to make people aware of them, until we get a chance
to address them.

The first issue is that show --format=raw --part on a message/rfc822
part is throwing a gmime exception, even though notmuch is still
producing output and returning successfully.  I just sent a patch to the
list addressing the issues.  However, the test suite was apparently
unable to catch that something unexpected was being output to stderr, so
we still need to address that.

Another issue is that we're no longer outputting any of the headers of
message/rfc822 parts.  This shouldn't be too hard to hack back in, so
hopefully I can get to that this weekend.

There was also a problem with the emacs display of message/rfc822 parts,
and I just sent a patch to the list about that as well.

However, there is a larger issue related to the ones above which is that
message parts in general are not being handled consistently, including
the top level message.  amdragon and I were actually discussing this on
irc the other day.  A possible solution is to make a general
message-part-handling function, that handles output of headers and the
message body, and call that function both on the top level message and
on any message sub parts.  I think that would make things a lot cleaner,
and would make the output more consistent and intuitive.

A somewhat related issue is that the "raw" format for parts is not
really doing the expected thing in certain cases, particularly with
regards to message parts.  dkg and I sort of realized this when we were
reworking the part handling a couple weeks ago.  One expects, rightfully
so, that show --format=raw --part on a message part would output the
full, raw, well-formatted rfc822 message enclosed in that part.
Currently that is not the case, since, for instance, the headers are not
output and the part handling is recursing over all the message
sub-parts.

I don't know necessarily know the right solution for either of these
issues, although I have some ideas (assuming I don't run into gmime
limitations).  Feedback and suggestions would be wonderful.
Unfortunately I don't have time to work on any of these issues at the
moment (hopefully this weekend), but I just wanted to throw them out
there, in case anyone wants to tackle them before I get to them.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH] emacs: Fix handling of message/rfc822 parts.

[Jameson Graef Rollins]

After the recent part-handling overhaul, emacs handling of
message/rfc822 parts broke, not outputting the message contents.  This
"fixes" then handling as is, but there are still problems with how
notmuch is outputting message parts that needs to be addressed (for
instance, message headers are not being output at the moment).

This also indicates that we need a test for output of message parts in
emacs.
---
 emacs/notmuch-show.el |   27 ---
 1 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 9837c7a..714200a 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -516,21 +516,26 @@ current buffer, if possible."
   t)

 (defun notmuch-show-insert-part-message/rfc822 (msg part content-type nth 
depth declared-type)
-  (let* ((message-part (plist-get part :content))
-(inner-parts (plist-get message-part :content)))
-(notmuch-show-insert-part-header nth declared-type content-type nil)
-;; Override `notmuch-message-headers' to force `From' to be
-;; displayed.
-(let ((notmuch-message-headers '("From" "Subject" "To" "Cc" "Date")))
-  (notmuch-show-insert-headers (plist-get part :headers)))
-;; Blank line after headers to be compatible with the normal
-;; message display.
-(insert "\n")
+  (notmuch-show-insert-part-header nth declared-type content-type nil)
+  (let ((inner-parts (plist-get part :content))
+   (start (point)))
+(if (plist-member part :headers)
+   (progn
+ ;; Override `notmuch-message-headers' to force `From' to be
+ ;; displayed.
+ (let ((notmuch-message-headers '("From" "Subject" "To" "Cc" "Date")))
+   (notmuch-show-insert-headers (plist-get part :headers)))
+ ;; Blank line after headers to be compatible with the normal
+ ;; message display.
+ (insert "foo\n")))

 ;; Show all of the parts.
 (mapc (lambda (inner-part)
(notmuch-show-insert-bodypart msg inner-part depth))
- inner-parts))
+ inner-parts)
+
+(when notmuch-show-indent-multipart
+  (indent-rigidly start (point) 1)))
   t)

 (defun notmuch-show-insert-part-text/plain (msg part content-type nth depth 
declared-type)
-- 
1.7.4.4

[PATCH] Do not attept to output part raw if part is not GMimePart.

[Jameson Graef Rollins]

This was a minor oversite in checking of part type when outputing
content raw.  This was causing gmime was to throw an exception to
stderr.

Unfortunately the gmime exception was not being caught by notmuch, or
the test suite.  I'm not sure if notmuch should have done anything in
this case, but certainly the test suite should be capable of detecting
that something unexpected was output to stderr.
---
 notmuch-show.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index 9267d02..3b4f775 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -646,14 +646,15 @@ format_part_content_raw (GMimeObject *part)
 {
 GMimeStream *stream_stdout;
 GMimeStream *stream_filter = NULL;
-GMimeDataWrapper *wrapper;
+GMimeDataWrapper *wrapper = NULL;

 stream_stdout = g_mime_stream_file_new (stdout);
 g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);

 stream_filter = g_mime_stream_filter_new (stream_stdout);

-wrapper = g_mime_part_get_content_object (GMIME_PART (part));
+if (GMIME_IS_PART (part))
+   wrapper = g_mime_part_get_content_object (GMIME_PART (part));

 if (wrapper && stream_filter)
g_mime_data_wrapper_write_to_stream (wrapper, stream_filter);
-- 
1.7.4.4

Decryption fails

[Jameson Graef Rollins]

On Tue, 31 May 2011 19:33:29 +0200, Felix Geller  wrote:
> I get the following trace when using show --decrypt to decrypt a
> specific message (have to kill the process to actually get the trace):
> 
> #0  0x0001006121a6 in poll ()
> #1  0x00010006d3d2 in gpg_ctx_op_step ()
> #2  0x00010006e5c7 in gpg_decrypt ()
> #3  0x0001000566cf in g_mime_multipart_encrypted_decrypt ()
> #4  0x0001a413 in show_message_part (part=0x10606fc20,
> #state=0x7fff5fbfd1c0, format=0x10002ef80, params=0x7fff5fbfd2c0,
> #first=1) at show-message.c:71
> 
> So I guess it ends up looping or waiting in poll(), but I can't tell why
> it would do that. I guess the next step is to post to the gmime mailing
> list, or?

Hey, Felix.  Yeah, I unfortunately don't have any other suggestions
other than asking the gmime folks.

Interestingly, I see the following message in your crypto test output:

  Error: search term did not match precisely one message.

which seems to indicate that the desired message wasn't actually
delivered properly, contrary to what the emacs delivery tests are
stating.  Not sure how that could be related, though, since it looks
like the trace that you show above definitely looks like gmime caught in
a poll loop.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: Decryption fails

[Jameson Graef Rollins]

On Tue, 31 May 2011 19:33:29 +0200, Felix Geller fgel...@gmail.com wrote:
 I get the following trace when using show --decrypt to decrypt a
 specific message (have to kill the process to actually get the trace):
 
 #0  0x0001006121a6 in poll ()
 #1  0x00010006d3d2 in gpg_ctx_op_step ()
 #2  0x00010006e5c7 in gpg_decrypt ()
 #3  0x0001000566cf in g_mime_multipart_encrypted_decrypt ()
 #4  0x0001a413 in show_message_part (part=0x10606fc20,
 #state=0x7fff5fbfd1c0, format=0x10002ef80, params=0x7fff5fbfd2c0,
 #first=1) at show-message.c:71
 
 So I guess it ends up looping or waiting in poll(), but I can't tell why
 it would do that. I guess the next step is to post to the gmime mailing
 list, or?

Hey, Felix.  Yeah, I unfortunately don't have any other suggestions
other than asking the gmime folks.

Interestingly, I see the following message in your crypto test output:

  Error: search term did not match precisely one message.

which seems to indicate that the desired message wasn't actually
delivered properly, contrary to what the emacs delivery tests are
stating.  Not sure how that could be related, though, since it looks
like the trace that you show above definitely looks like gmime caught in
a poll loop.

jamie.


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

[PATCH] Do not attept to output part raw if part is not GMimePart.

[Jameson Graef Rollins]

This was a minor oversite in checking of part type when outputing
content raw.  This was causing gmime was to throw an exception to
stderr.

Unfortunately the gmime exception was not being caught by notmuch, or
the test suite.  I'm not sure if notmuch should have done anything in
this case, but certainly the test suite should be capable of detecting
that something unexpected was output to stderr.
---
 notmuch-show.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index 9267d02..3b4f775 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -646,14 +646,15 @@ format_part_content_raw (GMimeObject *part)
 {
 GMimeStream *stream_stdout;
 GMimeStream *stream_filter = NULL;
-GMimeDataWrapper *wrapper;
+GMimeDataWrapper *wrapper = NULL;
 
 stream_stdout = g_mime_stream_file_new (stdout);
 g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
 
 stream_filter = g_mime_stream_filter_new (stream_stdout);
 
-wrapper = g_mime_part_get_content_object (GMIME_PART (part));
+if (GMIME_IS_PART (part))
+   wrapper = g_mime_part_get_content_object (GMIME_PART (part));
 
 if (wrapper  stream_filter)
g_mime_data_wrapper_write_to_stream (wrapper, stream_filter);
-- 
1.7.4.4

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

[PATCH] emacs: Fix handling of message/rfc822 parts.

[Jameson Graef Rollins]

After the recent part-handling overhaul, emacs handling of
message/rfc822 parts broke, not outputting the message contents.  This
fixes then handling as is, but there are still problems with how
notmuch is outputting message parts that needs to be addressed (for
instance, message headers are not being output at the moment).

This also indicates that we need a test for output of message parts in
emacs.
---
 emacs/notmuch-show.el |   27 ---
 1 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 9837c7a..714200a 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -516,21 +516,26 @@ current buffer, if possible.
   t)
 
 (defun notmuch-show-insert-part-message/rfc822 (msg part content-type nth 
depth declared-type)
-  (let* ((message-part (plist-get part :content))
-(inner-parts (plist-get message-part :content)))
-(notmuch-show-insert-part-header nth declared-type content-type nil)
-;; Override `notmuch-message-headers' to force `From' to be
-;; displayed.
-(let ((notmuch-message-headers '(From Subject To Cc Date)))
-  (notmuch-show-insert-headers (plist-get part :headers)))
-;; Blank line after headers to be compatible with the normal
-;; message display.
-(insert \n)
+  (notmuch-show-insert-part-header nth declared-type content-type nil)
+  (let ((inner-parts (plist-get part :content))
+   (start (point)))
+(if (plist-member part :headers)
+   (progn
+ ;; Override `notmuch-message-headers' to force `From' to be
+ ;; displayed.
+ (let ((notmuch-message-headers '(From Subject To Cc Date)))
+   (notmuch-show-insert-headers (plist-get part :headers)))
+ ;; Blank line after headers to be compatible with the normal
+ ;; message display.
+ (insert foo\n)))
 
 ;; Show all of the parts.
 (mapc (lambda (inner-part)
(notmuch-show-insert-bodypart msg inner-part depth))
- inner-parts))
+ inner-parts)
+
+(when notmuch-show-indent-multipart
+  (indent-rigidly start (point) 1)))
   t)
 
 (defun notmuch-show-insert-part-text/plain (msg part content-type nth depth 
declared-type)
-- 
1.7.4.4

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