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

[Dmitry Kurochkin]

Hi Jamie.

On Tue, 06 Sep 2011 09:43:00 -0700, Jameson Graef Rollins  wrote:
> On Fri,  3 Jun 2011 10:01:06 -0700, Jameson Graef Rollins  finestructure.net> wrote:
> > 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.
> 
> I'm finding it perplexing that this patch still hasn't been applied,
> considering how small it is and that it fixes a real bug.  Isn't anyone
> else experiencing this same issue?  I would really like to hear either
> way, if people either are or are *not* experiencing this issue.
> 
> To reiterate, this bug can be triggered very simply with the following
> command:
> 
> $ notmuch show --part=1 --format=raw id:"87wrgccedd.fsf at 
> yoom.home.cworth.org" >/dev/null
> 
> Please do let me know want you find.
> 

For me this results in:

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

(process:15727): gmime-CRITICAL **: g_mime_part_get_content_object: assertion 
`GMIME_IS_PART (mime_part)' failed

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

(process:15727): gmime-CRITICAL **: g_mime_part_get_content_object: assertion 
`GMIME_IS_PART (mime_part)' failed

HTH,
  Dmitry

> jamie.
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Do not import notmuch in setup.py (again).

[Sebastian Spaeth]

On Mon, 05 Sep 2011 09:04:54 -0300, David Bremner  wrote:
>  On Wed, 24 Aug 2011 09:20:51 +0200, Sebastian Spaeth wrote
>  > Ahh, sorry, I must have missed that patch (or forgotten about it). I
>  > solved this now by having the version number in version.py (which
>  > contains nothing else, so David Bremner can easily overwrite it with
>  > makefile magic :-)).
> 
> I pushed a test to be run during the release process, to see that the
> versions of the lib and the python bindings match. I decided against
> automagically overwriting the file (for now), since I'd prefer the
> committed version.py match the tarball, and I'm not super happy with
> auto-commiting things.

Sounds fair enough. You've got hereby got a blanket permission to fudge
the version number as needed for the release process ;-)

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110906/f31ddf28/attachment.pgp>

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

[Jameson Graef Rollins]

Everyone that I know of who has tried to reproduce this bug has been
able to.  I vote that we include this patch in 0.8, so that we can get
it out of the way.

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/20110906/5640639c/attachment.pgp>

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

[Jameson Graef Rollins]

On Fri,  3 Jun 2011 10:01:06 -0700, Jameson Graef Rollins  wrote:
> 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.

I'm finding it perplexing that this patch still hasn't been applied,
considering how small it is and that it fixes a real bug.  Isn't anyone
else experiencing this same issue?  I would really like to hear either
way, if people either are or are *not* experiencing this issue.

To reiterate, this bug can be triggered very simply with the following
command:

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

Please do let me know want you find.

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/20110906/ca3d3122/attachment.pgp>

test case for message display

[David Bremner]

I haven't had a chance to investigate it, but here is a message that
show a bug in message display, I think in citation/top-posting hiding.
Hiding the whole message would be ok, but there is no un-hide button.

-- next part --
An embedded message was scrubbed...
From: Tino Keitel <tino.keitel+syncevolut...@tikei.de>
Subject: Re: [SyncEvolution] Multi-point sync
Date: Tue, 6 Sep 2011 08:27:10 +0200
Size: 2834
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110906/34c64fca/attachment.mht>

[PATCH] Add NEWS item output improvements to rfc822 part handling.

[David Bremner]

On Tue,  6 Sep 2011 00:17:30 -0700, Jameson Graef Rollins  wrote:
> ---
>  NEWS |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)

Pushed, with thanks!

d

[PATCH] emacs: Sort saved searches

[Adam Wolfe Gordon]

Jani Nikula wrote:
> 
> Hmm. Let's look at this from another perspective: do you know if there's
> a reasonable way to make ordering of the customized saved searches
> easier? It's not exactly user friendly to move items up and down in the
> list. Or to sort them.
> 
> On the other hand, the tags are sorted. Saved searches are not. Should
> it be possible to display tags in user defined order...?
> 
> I know I can twist this the way I want and carry my own modifications, 
> but I'd like to make notmuch user friendly for people who don't know 
> elisp.
> 

My two cents on this, as someone who uses notmuch as a Gmail-alike for
non-Gmail email:

I keep my saved searches in a particular order, kind of emulating the Gmail
sidebar: unread, inbox, sent, all mail.  Putting these in alphabetical order
either direction would not achieve the goal of having the most
used/important saved searches first (i.e. I hardly ever use all mail, so it
shouldn't be first in the list).

The tags list, on the other hand, I like having sorted to make tags easy to
find.  It has a different purpose than saved searches for me, so its
behavior is different.

I think having an option to sort the saved searches is a fine idea.  The
Emacs Way would probably be to have an option for the sort order that takes
the name of a function, which is called to sort the searches.  My first
thought is that this isn't very user-friendly.  But, thinking about it a bit
more, if the default causes the searches to be sorted alphabetically, and
setting the value to nil causes them not to be sorted, then it's
user-friendly for the two most common cases, and still 100% customizable for
those who want different sort orders.

-
-- 
Adam Wolfe Gordon
--
View this message in context: 
http://notmuch.198994.n3.nabble.com/PATCH-emacs-Sort-saved-searches-tp3304068p3313863.html
Sent from the notmuch mailing list archive at Nabble.com.

[PATCH] Add NEWS item output improvements to rfc822 part handling.

[Jameson Graef Rollins]

---
 NEWS |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index f715142..65aca75 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+Notmuch 0.8 (2011-09-05)
+
+
+Improved handling of message/rfc822 parts
+
+  Both in the CLI and the emacs interface.  Output of rfc822 parts now
+  includes the primary headers, as well as the body and all subparts.
+  Output of the completely raw rfc822-formatted message, including all
+  headers, is unfortunately not yet supported (but hopefully will be
+  soon).
+
 Notmuch 0.7 (2011-08-01)
 

-- 
1.7.5.4

Release O.8? Why not.

[David Bremner]

OK, so we are a bit behind schedule, but I declare a feature
freeze.  I have pushed a tag 0.8_rc0 to mark the occasion.

At this point I need some help with the NEWS file, and of course if any
showstopper bugs are found with 0.8_rc0, we can fix them somehow.

As far as changes we need to document, I know about 

- python bindings changes
- ruby bindings changes
- jrollins' rfc822 updates
- one other emacs specific bugfix

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

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

[David Bremner]

On Mon,  5 Sep 2011 12:01:46 -0700, Jameson Graef Rollins  wrote:
> 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:

I have pushed the remaining 3 patches in the series. Namely this one,
and the last 2 from the previous series. I added a brief note to the
commit message about the one test which fails.  I think on the whole the
approach Jamie took of writing the test as the specification is the
correct one. 

d

[PATCH] Add NEWS item output improvements to rfc822 part handling.

[Jameson Graef Rollins]

---
 NEWS |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index f715142..65aca75 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+Notmuch 0.8 (2011-09-05)
+
+
+Improved handling of message/rfc822 parts
+
+  Both in the CLI and the emacs interface.  Output of rfc822 parts now
+  includes the primary headers, as well as the body and all subparts.
+  Output of the completely raw rfc822-formatted message, including all
+  headers, is unfortunately not yet supported (but hopefully will be
+  soon).
+
 Notmuch 0.7 (2011-08-01)
 
 
-- 
1.7.5.4

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

Re: [PATCH] Add NEWS item output improvements to rfc822 part handling.

[David Bremner]

On Tue,  6 Sep 2011 00:17:30 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 ---
  NEWS |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

Pushed, with thanks!

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

test case for message display

[David Bremner]

I haven't had a chance to investigate it, but here is a message that
show a bug in message display, I think in citation/top-posting hiding.
Hiding the whole message would be ok, but there is no un-hide button.

---BeginMessage---
--- Original message ---
 From: Ross Vandegrift r...@kallisti.us
 To: syncevolut...@syncevolution.org
 Sent: 5.9.'11,  22:59
 What's the best way to do this without messing up data or creating
 duplicates?  If I just take the synced phone and sync it with the
 laptop, will that work?

It should work. I did this once to test server operation. In my production 
setup, I use a dedicated syncevolution server that my desktop, laptop and 
phone use for syncing via HTTPS.

Regards,
Tino 
___
SyncEvolution mailing list
syncevolut...@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
---End Message---
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Sort saved searches

[Adam Wolfe Gordon]

Jani Nikula wrote:
 
 Hmm. Let's look at this from another perspective: do you know if there's
 a reasonable way to make ordering of the customized saved searches
 easier? It's not exactly user friendly to move items up and down in the
 list. Or to sort them.
 
 On the other hand, the tags are sorted. Saved searches are not. Should
 it be possible to display tags in user defined order...?
 
 I know I can twist this the way I want and carry my own modifications, 
 but I'd like to make notmuch user friendly for people who don't know 
 elisp.
 

My two cents on this, as someone who uses notmuch as a Gmail-alike for
non-Gmail email:

I keep my saved searches in a particular order, kind of emulating the Gmail
sidebar: unread, inbox, sent, all mail.  Putting these in alphabetical order
either direction would not achieve the goal of having the most
used/important saved searches first (i.e. I hardly ever use all mail, so it
shouldn't be first in the list).

The tags list, on the other hand, I like having sorted to make tags easy to
find.  It has a different purpose than saved searches for me, so its
behavior is different.

I think having an option to sort the saved searches is a fine idea.  The
Emacs Way would probably be to have an option for the sort order that takes
the name of a function, which is called to sort the searches.  My first
thought is that this isn't very user-friendly.  But, thinking about it a bit
more, if the default causes the searches to be sorted alphabetically, and
setting the value to nil causes them not to be sorted, then it's
user-friendly for the two most common cases, and still 100% customizable for
those who want different sort orders.

-
-- 
Adam Wolfe Gordon
--
View this message in context: 
http://notmuch.198994.n3.nabble.com/PATCH-emacs-Sort-saved-searches-tp3304068p3313863.html
Sent from the notmuch mailing list archive at Nabble.com.
___
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]

Everyone that I know of who has tried to reproduce this bug has been
able to.  I vote that we include this patch in 0.8, so that we can get
it out of the way.

jamie.


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

RFC/PATCH emacs attachment handling

[Mark Walters]

Hello

I have modified the emacs interface for handling attachments by adding
a keymap to the attachment button. For example pressing v when on an
attachment button views the attachment (using the mailcap method) and
pressing s saves the attachment. I find this makes it a lot easier
when dealing with message with lots of attachments.

Other comments:

Viewing a text/html button opens the part in the mailcap defined html viewer.

Viewing a part with no mailcap entry just offers to save it.

In this version I make the button default to viewing: this is obviously
trivial to change but I am not sure what the right way to make that
user-configurable is.  

Finally, I have also mapped the key o (other/open with) on a button to
open with user chosen program. This could be split out into a separate
patch if preferred.

Best wishes

Mark

---
 emacs/notmuch-show.el |   76 +++-
 1 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 90f9af7..3a025c5 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -267,10 +267,21 @@ message at DEPTH in the current thread.
(run-hooks 'notmuch-show-markup-headers-hook)
 
 (define-button-type 'notmuch-show-part-button-type
-  'action 'notmuch-show-part-button-action
+  'action 'notmuch-show-part-button-view-action
+  'keymap 'notmuch-show-part-button-map
   'follow-link t
   'face 'message-mml)
 
+(defvar notmuch-show-part-button-map
+  (let ((map (make-sparse-keymap)))
+   (set-keymap-parent map button-map)
+   (define-key map s 'notmuch-show-part-button-save-action)
+   (define-key map v 'notmuch-show-part-button-view-action)
+   (define-key map o 'notmuch-show-part-button-interactively-view-action)
+map)
+  Submap for button commands)
+(fset 'notmuch-show-part-button-map notmuch-show-part-button-map)
+
 (defun notmuch-show-insert-part-header (nth content-type declared-type 
optional name comment)
   (let ((button))
 (setq button
@@ -285,7 +296,8 @@ message at DEPTH in the current thread.
])
   :type 'notmuch-show-part-button-type
   :notmuch-part nth
-  :notmuch-filename name))
+  :notmuch-filename name
+  :notmuch-content-type content-type))
 (insert \n)
 ;; return button
 button))
@@ -309,6 +321,28 @@ message at DEPTH in the current thread.
;; ange-ftp, which is reasonable to use here.
(mm-write-region (point-min) (point-max) file nil nil nil 
'no-conversion t)
 
+(defun notmuch-show-view-part (message-id nth content-type)
+  (let ((process-crypto notmuch-show-process-crypto))
+(with-temp-buffer
+  (setq notmuch-show-process-crypto process-crypto)
+  ;; Always acquires the part via `notmuch part', even if it is
+  ;; available in the JSON output.
+  (insert (notmuch-show-get-bodypart-internal message-id nth))
+  ;; set mm-inlined-types to nil to force an external viewer
+  (let ((handle (mm-make-handle (current-buffer) (list content-type)))
+   (mm-inlined-types nil))
+   (mm-display-part handle)
+
+(defun notmuch-show-interactively-view-part (message-id nth content-type)
+  (let ((process-crypto notmuch-show-process-crypto))
+(with-temp-buffer
+  (setq notmuch-show-process-crypto process-crypto)
+  ;; Always acquires the part via `notmuch part', even if it is
+  ;; available in the JSON output.
+  (insert (notmuch-show-get-bodypart-internal message-id nth))
+  (let ((handle (mm-make-handle (current-buffer) (list content-type
+   (mm-interactively-view-part handle)
+
 (defun notmuch-show-mm-display-part-inline (msg part content-type content)
   Use the mm-decode/mm-view functions to display a part in the
 current buffer, if possible.
@@ -1418,12 +1452,38 @@ buffer.
 
 ;; Commands typically bound to buttons.
 
-(defun notmuch-show-part-button-action (button)
-  (let ((nth (button-get button :notmuch-part)))
-(if nth
-   (notmuch-show-save-part (notmuch-show-get-message-id) nth
-   (button-get button :notmuch-filename))
-  (message Not a valid part (is it a fake part?).
+(defun notmuch-show-part-button-save-action (optional button)
+  (interactive)
+  (let ((button (or button (button-at (point)
+(if (not button)
+   nil
+  (let ((nth (button-get button :notmuch-part)))
+   (if nth
+   (notmuch-show-save-part (notmuch-show-get-message-id) nth
+   (button-get button :notmuch-filename))
+ (message Not a valid part (is it a fake part?).))
+
+(defun notmuch-show-part-button-view-action (optional button)
+  (interactive)
+  (let ((button (or button (button-at (point)
+(if (not button)
+   nil
+  (let ((nth (button-get button :notmuch-part)))
+   (if nth
+   (notmuch-show-view-part (notmuch-show-get-message-id) nth
+