[notmuch] Rework of attachment saving

I think I've reworked the attachment savings to behave as we've been discussing. I don't know anything about the button handling so I haven't attempted to implement the direct manipulation approach of of saving using the buttons. That would certainly be nice to have however and I belive this

[notmuch] [PATCH] Rework saving of attachments.

From: Keith Amidon ke...@nicira.com With this commit notmuch-show-mode supports saving a single attachment from a message (bound to 'w') and saving all attachments to the message (bound to 'W'). The new variable notmuch-default-save-dir allows the user to specify a directory within which

Re: [notmuch] [PATCH] Support for deletion by the emacs client

On Sun, 13 Dec 2009 12:52:56 +0100, Matthieu Lemerre ra...@free.fr wrote: I tried notmuch and I really like it. I like having an emacs email client, but was proficient with none of them (neither with non-emacs clients, btw). Notmuch really seems the way to go. Hi Matthieu, welcome to notmuch!

Re: [notmuch] RFC: output json from notmuch?

On Sun, 13 Dec 2009 19:21:02 -0400, David Bremner da...@tethera.net wrote: It would be nice to have more structured output from notmuch-show. I decided to investigate sexp (i.e. lisp) and json output. Thanks, David! Then I found that json parsing is provided by the library json.el shipped

Re: [notmuch] RFC: output json from notmuch?

On Sun, 13 Dec 2009 16:05:07 -0800, Scott Robinson sc...@quadhome.com wrote: I have a patch for a --output=(text|json) for both notmuch-show and notmuch-search. I mentioned it earlier on the list, and no one seemed to have any interest. Hi Scott, I remember you mentioning this earlier, but I

Re: [notmuch] RFC: output json from notmuch?

On Sun, 13 Dec 2009 20:42:07 -0400, David Bremner brem...@unb.ca wrote: On a different topic (and in response to Carl and your earlier discussion), as a counter-weight to the desire to avoid dependencies (which I agree with), I also think we should be careful about how many embedded copies of

Re: [notmuch] Rework of attachment saving

On Mon, 14 Dec 2009 10:13:57 -0800, cama...@picnicpark.org wrote: I think I've reworked the attachment savings to behave as we've been discussing. I don't know anything about the button handling so I haven't attempted to implement the direct manipulation approach of of saving using the

[notmuch] [patch] store folder information

Hi there, I've patched notmuch to retain information on which folder emails are stored in. This makes the transition from a folders-and-procmail model somewhat easier. The resulting changes are attached. Andreas From 179af7f436d8c21bad90e7eb88fc17c56f83c26c Mon Sep 17 00:00:00 2001 From:

Re: [notmuch] RFC: output json from notmuch?

On Mon, 14 Dec 2009 14:30:45 -0800, Carl Worth cwo...@cworth.org wrote: I'm still not sure of the need to depend on a library just to *generate* any particular format. I would expect that job to be so constrained as to be almost trivial. I won't necessarily block a patch based on that, but I

[notmuch] [PATCH] emacs: Don't eat last newline character of citations

In case of a citation following immediately new contents. When the citation was collapsed: [1-line citation. Click/Enter to show.] Lorem ipsum dolor sit amet, consectetur adipisicin When it was expanded: [10-line citation. Click/Enter to show.] > Lorem ipsum dolor sit amet,

[notmuch] RFC: output json from notmuch?

Excerpts from David Bremner's message of Mon Dec 14 00:21:02 +0100 2009: > So, do people think this is a reasonable idea to persue? JSON was actually the first thing I thought of when I first saw the output of notmuch-show. I think it's a much more natural fit for notmuch than say, sexps, since

[notmuch] [PATCH 2/4] emacs: Connect two hunk of citations if only blank separated

Also eats extra blanks between citations and content, which may not be desired behavior. Signed-off-by: Kan-Ru Chen --- notmuch.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch.el b/notmuch.el index 5823094..1722474 100644 --- a/notmuch.el +++ b/notmuch.el @@

[notmuch] [PATCH 4/4] emacs: Use font-lock-comment-face to highlight citation button

Signed-off-by: Kan-Ru Chen --- notmuch.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch.el b/notmuch.el index db8f899..ed96dfa 100644 --- a/notmuch.el +++ b/notmuch.el @@ -581,7 +581,7 @@ which this thread was originally shown." (define-button-type

[notmuch] [PATCH 3/4] emacs: Some cleanup.

Signed-off-by: Kan-Ru Chen --- notmuch.el |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/notmuch.el b/notmuch.el index 1722474..db8f899 100644 --- a/notmuch.el +++ b/notmuch.el @@ -611,11 +611,10 @@ which this thread was originally shown."

[notmuch] [PATCH-v2] Don't eat last newline character of citations

This patch series fixed the indentation problem of git HEAD and did some minor cleanup of (- (..) 1) usage. The second patch connects two citations block if them are blank line separated, for example: > block 1 > block 1 > block 2 Will be treat as one citation block. The side

[notmuch] [PATCH 1/4] emacs: Don't eat last newline character of citations

In case of a citation following immediately new contents. When the citation was collapsed: [1-line citation. Click/Enter to show.] Lorem ipsum dolor sit amet, consectetur adipisicin When it was expanded: [10-line citation. Click/Enter to show.] > Lorem ipsum dolor sit amet,

[notmuch] Rework of attachment saving

I think I've reworked the attachment savings to behave as we've been discussing. I don't know anything about the button handling so I haven't attempted to implement the direct manipulation approach of of saving using the buttons. That would certainly be nice to have however and I belive this

[notmuch] [PATCH] Rework saving of attachments.

From: Keith Amidon With this commit notmuch-show-mode supports saving a single attachment from a message (bound to 'w') and saving all attachments to the message (bound to 'W'). The new variable notmuch-default-save-dir allows the user to specify a directory within which

[notmuch] [PATCH] Support for deletion by the emacs client

plication/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091214/0f0c84e8/attachment.pgp>

[notmuch] RFC: output json from notmuch?

ilable URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091214/573c75e7/attachment.pgp>

[notmuch] RFC: output json from notmuch?

I'd be glad to evaluate different options here. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091214/28e56f13/attachment.pgp>

[notmuch] RFC: output json from notmuch?

re parsing JSON, then I'd be happy to depend on a library for that.) -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments

[notmuch] Rework of attachment saving

- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091214/1053e7f2/attachment.pgp>

[notmuch] [patch] store folder information

: 0001-Preseve-folder-information-when-indexing.patch Type: text/x-patch Size: 4899 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091214/a15c2776/attachment.bin> -- next part -- A non-text attachment was scrubbed..

[notmuch] RFC: output json from notmuch?

On Mon, 14 Dec 2009 14:30:45 -0800, Carl Worth wrote: > I'm still not sure of the need to depend on a library just to *generate* > any particular format. I would expect that job to be so constrained as > to be almost trivial. I won't necessarily block a patch based on that, > but I think we