[notmuch] RFC: output json from notmuch?

2009-12-14 Thread David Bremner
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 should at least look at how easy it would be to just emit
> the syntax manually.

OK, I'll wait for Scott's patch, and see how he is using cJSON. Just
stealing a few functions might be the way to go.

The cJSON code is less horrifying after running through indent. Now all
we need is "indent --carl" :)

d



[notmuch] Rework of attachment saving

2009-12-14 Thread Carl Worth
On Mon, 14 Dec 2009 10:13:57 -0800, camalot at 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 buttons.  That would certainly be nice to have
> however and I belive this change should make it easy for someone who
> knows how buttons work to implement it.

Excellent, Keith!

I'm just writing to say thanks for now, and I will review the patch in
more detail later.

-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/1053e7f2/attachment.pgp>


[notmuch] RFC: output json from notmuch?

2009-12-14 Thread Carl Worth
On Sun, 13 Dec 2009 20:42:07 -0400, David Bremner  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 code there are, from the point of keeping up with
> security problems.  This is probably a bias I picked up from Debian.

Embedded copies of code already packaged in Debian is something to
avoid, definitely. I'm not actively against having dependencies for
functionality that makes sense.

For example, the current libsha1 code in notmuch has been the subject of
a debate about embedded code copies here on the list already. If
somebody would like to maintain that code as a Debian package, then I
would be happy to depend on it that way rather than having an embedded
copy inside notmuch.

For something like JSON output, I really can't see how we need an
external library. The job we're talking about is changing our current
delimiters and then fixing our code to properly quote delimiters
appearing in the content. That doesn't sound like a job that needs a
library.

(Meanwhile, if we were 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/20091214/278655f1/attachment.pgp>


[notmuch] RFC: output json from notmuch?

2009-12-14 Thread Carl Worth
On Sun, 13 Dec 2009 16:05:07 -0800, Scott Robinson  
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 didn't remember seeing the
actual patch? Did I miss it? I also didn't find it again when searching
and re-reading the thread. hopefully this isn't a case of my mail
client's search feature failing me... ;-)

> Is it worth updating to HEAD and trying again?

If you'd like to, please feel free. 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?

2009-12-14 Thread Carl Worth
On Sun, 13 Dec 2009 19:21:02 -0400, David Bremner  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 with emacs23, so I decided to play with json a bit.

That sounds very promising. I wasn't aware this existed inside emacs
already.

> I settled on the jansson library (http://www.digip.org/jansson/)
> because it seemed to have a sane api and documentation, but there are
> many choices.  I'll follow up with the actual patch, but the idea is to
> replace the printfs in show_message with calls to set (key,value) pairs
> in a json object, and output it at the end.

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 should at least look at how easy it would be to just emit
the syntax manually.

> So, do people think this is a reasonable idea to persue?

I do, yes. The current lack of full quoting is an obnoxious bug.

> 1) it adds a dependency, but not a heavy one. jansson is about 300k
> installed on debian/i386

That might be acceptable. And we might rewrite the patch to avoid it as
well. I'd like to see what that would take.

> 2) It might mean that people using emacs22 might have to score
> json.el from somewhere; I'm not sure.

Currently, it sounds like notmuch is entirely unusable from emacs22, so
I'm really not too concerned about one more thing that requires emacs
23.

> 3) There is some increase in memory use since the whole thread has
> to be built as a json object before being output.

Right. That would be another reason to just stream the output
manually. The syntax doesn't require things like knowing the size of an
array before emitting the first element, right?

> 4) Of course jansson is doing it's own reference counting memory
> managment, and not using talloc. But we already have glib...

It's not evil to not use talloc. So not an issue there.

-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/573c75e7/attachment.pgp>


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

2009-12-14 Thread Carl Worth
On Sun, 13 Dec 2009 12:52:56 +0100, Matthieu Lemerre  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!

> However, support for deletion is important to me. Here is a first patch
> that implements it for the emacs interface.

Thanks for the contribution. I'll queue this and review it soon. You'll
notice my review-and-merge pattern is very bursty, and I happen to be
between bursts at the moment.

(Of course, others can review too---I'm much more likely to merge code
if it has one or two Reviewed-By comments on the list.)

> I also added a command history to notmuch-search.

That sounds very nice! I'll steal that for command history for '|' which
I've been needing for a while.

> Now I'd like to write a command to expunge deleted mails; this shouldn't
> be difficult. Having notmuch detect that some mails disappeared and
> update the database seems more difficult, though.

That part I'll be doing. It's already on my TODO list and very highly
prioritized.

> PS: I have trouble understanding why space on the last message on a
> thread deletes the inbox tag. If you do it, then you mail becomes
> untagged and imo quite difficult to search. How is the mail flow
> supposed to work?

I've discussed previously that I plan to remove this behavior from the
function bound to space. Instead, it will require an explicit action to
archive a thread, ('a' to archive and advance to the next thread, and
'x' to archive and exit back to the search results).

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


[notmuch] [patch] store folder information

2009-12-14 Thread Andreas Klöckner
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
-- next part --
A non-text attachment was scrubbed...
Name: 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...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091214/a15c2776/attachment.pgp>


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

2009-12-14 Thread Kan-Ru Chen

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-button-invisibility-toggle-type
   'action 'notmuch-toggle-invisible-action
   'follow-link t
-  'face "default")
+  'face 'font-lock-comment-face)
 (define-button-type 'notmuch-button-citation-toggle-type 'help-echo "mouse-1, 
RET: Show citation"
   :supertype 'notmuch-button-invisibility-toggle-type)
 (define-button-type 'notmuch-button-signature-toggle-type 'help-echo "mouse-1, 
RET: Show signature"
-- 
1.6.5.5



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

2009-12-14 Thread Kan-Ru Chen

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."
   (invis-spec (make-symbol "notmuch-citation-region")))
   (add-to-invisibility-spec invis-spec)
  (overlay-put overlay 'invisible invis-spec)
-  (let ((p (point-marker))
-(cite-button-text
+  (let ((cite-button-text
  (concat "["  (number-to-string (count-lines beg-sub 
(point)))
  "-line citation. Click/Enter to show.]")))
-(goto-char (- beg-sub 1))
+(goto-char (1- beg-sub))
 (insert (concat "\n" indent))
 (insert-button cite-button-text
'invisibility-spec invis-spec
@@ -624,7 +623,7 @@ which this thread was originally shown."
   
   (move-to-column depth)
   (if (looking-at notmuch-show-signature-regexp)
- (let ((sig-lines (- (count-lines beg-sub end) 1)))
+ (let ((sig-lines (1- (count-lines beg-sub end
(if (<= sig-lines notmuch-show-signature-lines-max)
(progn
   (let ((invis-spec (make-symbol "notmuch-signature-region")))
@@ -632,7 +631,7 @@ which this thread was originally shown."
 (overlay-put (make-overlay beg-sub end)
  'invisible invis-spec)

-(goto-char (- beg-sub 1))
+(goto-char (1- beg-sub))
 (insert (concat "\n" indent))
 (let ((sig-button-text (concat "[" (number-to-string 
sig-lines)
"-line signature. 
Click/Enter to show.]")))
-- 
1.6.5.5



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

2009-12-14 Thread Kan-Ru Chen
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
@@ -603,7 +603,7 @@ which this thread was originally shown."
   (move-to-column depth)
   (if (looking-at citation)
  (progn
-   (while (looking-at citation)
+   (while (looking-at (concat citation "\\|^$"))
  (forward-line)
  (move-to-column depth))
(end-of-line 0)
-- 
1.6.5.5



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

2009-12-14 Thread Kan-Ru Chen
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, consectetur adipisicin

The indentation was wrong.

Signed-off-by: Kan-Ru Chen 
---
 notmuch.el |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 97914f2..5823094 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -606,7 +606,8 @@ which this thread was originally shown."
(while (looking-at citation)
  (forward-line)
  (move-to-column depth))
-   (let ((overlay (make-overlay beg-sub (point)))
+   (end-of-line 0)
+   (let ((overlay (make-overlay beg-sub  (1+ (point-marker
   (invis-spec (make-symbol "notmuch-citation-region")))
   (add-to-invisibility-spec invis-spec)
  (overlay-put overlay 'invisible invis-spec)
-- 
1.6.5.5



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

2009-12-14 Thread Kan-Ru Chen
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 effect is that any blank
line following the citation will be hidden, too.

The fourth patch is intend to decorate the citation button with
font-lock-comment-face so that the button can stand out form other
contents.

Cheers,
Kanru



[notmuch] [PATCH] Rework saving of attachments.

2009-12-14 Thread cama...@picnicpark.org
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 attachments should
be saved by default.  The user can modify this default path, even
specifying a non-existent directory path, in which case he or she will
be prompted to create the path.  Reporting of the actions taken is
also improved.
---
 notmuch.el |   93 ++-
 1 files changed, 72 insertions(+), 21 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 97914f2..b72548d 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -64,7 +64,8 @@
 (define-key map "f" 'notmuch-show-forward-current)
 (define-key map "r" 'notmuch-show-reply)
 (define-key map "|" 'notmuch-show-pipe-message)
-(define-key map "w" 'notmuch-show-save-attachments)
+(define-key map "w" 'notmuch-show-save-attachment)
+(define-key map "W" 'notmuch-show-save-all-attachments)
 (define-key map "V" 'notmuch-show-view-raw-message)
 (define-key map "v" 'notmuch-show-view-all-mime-parts)
 (define-key map "-" 'notmuch-show-remove-tag)
@@ -98,6 +99,9 @@ pattern can still test against the entire line).")
 (defvar notmuch-command "notmuch"
   "Command to run the notmuch binary.")

+(defvar notmuch-default-save-dir (file-name-as-directory (getenv "HOME" ))
+  "Default directory in which attachments are saved.")
+
 (defvar notmuch-show-message-begin-regexp"\fmessage{")
 (defvar notmuch-show-message-end-regexp  "\fmessage}")
 (defvar notmuch-show-header-begin-regexp "\fheader{")
@@ -329,28 +333,75 @@ buffer."
  mm-handle)
 count))

-(defun notmuch-save-attachments (mm-handle  queryp)
-  (notmuch-foreach-mime-part
-   (lambda (p)
- (let ((disposition (mm-handle-disposition p)))
-   (and (listp disposition)
-(or (equal (car disposition) "attachment")
-(and (equal (car disposition) "inline")
- (assq 'filename disposition)))
-(or (not queryp)
-(y-or-n-p
- (concat "Save '" (cdr (assq 'filename disposition)) "' ")))
-(mm-save-part p
-   mm-handle))
-
-(defun notmuch-show-save-attachments ()
-  "Save all attachments from the current message."
-  (interactive)
+(defun notmuch-attachment-q (mm-handle)
+  (let ((disposition (mm-handle-disposition p)))
+(and (listp disposition)
+ (assq 'filename disposition
+
+(defun notmuch-get-save-path (filename default-dir)
+  (let ((savepath nil))
+(while (not savepath)
+  (let* ((ddir (file-name-as-directory default-dir))
+ (fn (read-file-name "Save to: " ddir nil nil filename))
+ (efn (expand-file-name fn))
+ (dir (file-name-directory efn)))
+(when (not (file-accessible-directory-p dir))
+  (when (y-or-n-p (concat "Create directory " dir " "))
+(make-directory dir t)))
+(if (file-accessible-directory-p dir)
+(setq savepath fn)
+  (setq default-dir (file-name-directory fn)
+savepath))
+
+(defun notmuch-save-attachment (mm-handle default-dir)
+  "Save the current attachment part to a file."
+  (cond ((not (notmuch-attachment-q mm-handle))
+ (message "Current part is not an attachment.")
+ nil)
+(t
+ (let* ((fn (cdr (assq 'filename (mm-handle-disposition mm-handle
+(savepath (notmuch-get-save-path fn default-dir)))
+   (mm-save-part-to-file mm-handle savepath)
+   savepath
+
+(defun notmuch-save-attachment-num (mm-handle part-num)
+  "Save the nth part number"
+  (let ((nfound 0)
+(nsaved 0))
+(notmuch-foreach-mime-part
+ (lambda (p)
+   (when (notmuch-attachment-q p)
+ (cond ((equal (+ 1 nfound) part-num)
+(when (notmuch-save-attachment p notmuch-default-save-dir)
+  (incf nsaved
+ (incf nfound))) mm-handle)
+(equal nsaved 1)))
+
+(defun notmuch-show-save-attachment (num)
+  "Save a single attachment."
+  (interactive "p")
   (with-current-notmuch-show-message
(let ((mm-handle (mm-dissect-buffer)))
- (notmuch-save-attachments
-  mm-handle (> (notmuch-count-attachments mm-handle) 1
-  (message "Done"))
+ (if (notmuch-save-attachment-num mm-handle num)
+ (message "Attachment %d saved." num)
+   (message "Failed to save attachment.")
+
+(defun notmuch-show-save-all-attachments ()
+  "Save all attachments of a message to a directory."
+  (interactive)
+  (with-current-notmuch-show-message
+   (let ((nfound 0)
+ (nsaved 0)
+ (default-dir notmuch-default-save-dir)
+ (mm-handle (mm-dissect-buffer)))
+ (notmuch-foreach-mime-part
+  (lambda (p)
+(when (notmuch-attachment-q p)
+  

[notmuch] Rework of attachment saving

2009-12-14 Thread cama...@picnicpark.org
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 change should make it easy for someone who
knows how buttons work to implement it.

 --- Keith



[notmuch] RFC: output json from notmuch?

2009-12-14 Thread Marten Veldthuis
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 most languages will have libraries for JSON,
which will be nicer to interfaces other than the emacs one.
-- 
- Marten


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

2009-12-14 Thread Kan-Ru Chen
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, consectetur adipisicin

The indentation was wrong.

Signed-off-by: Kan-Ru Chen 
---
 notmuch.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 97914f2..aa6bc60 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -606,6 +606,7 @@ which this thread was originally shown."
(while (looking-at citation)
  (forward-line)
  (move-to-column depth))
+   (end-of-line 0)
(let ((overlay (make-overlay beg-sub (point)))
   (invis-spec (make-symbol "notmuch-citation-region")))
   (add-to-invisibility-spec invis-spec)
-- 
1.6.5.5



[notmuch] Rework of attachment saving

2009-12-14 Thread camalot
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 change should make it easy for someone who
knows how buttons work to implement it.

 --- Keith

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


[notmuch] [PATCH] Rework saving of attachments.

2009-12-14 Thread camalot
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 attachments should
be saved by default.  The user can modify this default path, even
specifying a non-existent directory path, in which case he or she will
be prompted to create the path.  Reporting of the actions taken is
also improved.
---
 notmuch.el |   93 ++-
 1 files changed, 72 insertions(+), 21 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 97914f2..b72548d 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -64,7 +64,8 @@
 (define-key map f 'notmuch-show-forward-current)
 (define-key map r 'notmuch-show-reply)
 (define-key map | 'notmuch-show-pipe-message)
-(define-key map w 'notmuch-show-save-attachments)
+(define-key map w 'notmuch-show-save-attachment)
+(define-key map W 'notmuch-show-save-all-attachments)
 (define-key map V 'notmuch-show-view-raw-message)
 (define-key map v 'notmuch-show-view-all-mime-parts)
 (define-key map - 'notmuch-show-remove-tag)
@@ -98,6 +99,9 @@ pattern can still test against the entire line).)
 (defvar notmuch-command notmuch
   Command to run the notmuch binary.)
 
+(defvar notmuch-default-save-dir (file-name-as-directory (getenv HOME ))
+  Default directory in which attachments are saved.)
+
 (defvar notmuch-show-message-begin-regexp\fmessage{)
 (defvar notmuch-show-message-end-regexp  \fmessage})
 (defvar notmuch-show-header-begin-regexp \fheader{)
@@ -329,28 +333,75 @@ buffer.
  mm-handle)
 count))
 
-(defun notmuch-save-attachments (mm-handle optional queryp)
-  (notmuch-foreach-mime-part
-   (lambda (p)
- (let ((disposition (mm-handle-disposition p)))
-   (and (listp disposition)
-(or (equal (car disposition) attachment)
-(and (equal (car disposition) inline)
- (assq 'filename disposition)))
-(or (not queryp)
-(y-or-n-p
- (concat Save ' (cdr (assq 'filename disposition)) ' )))
-(mm-save-part p
-   mm-handle))
-
-(defun notmuch-show-save-attachments ()
-  Save all attachments from the current message.
-  (interactive)
+(defun notmuch-attachment-q (mm-handle)
+  (let ((disposition (mm-handle-disposition p)))
+(and (listp disposition)
+ (assq 'filename disposition
+
+(defun notmuch-get-save-path (filename default-dir)
+  (let ((savepath nil))
+(while (not savepath)
+  (let* ((ddir (file-name-as-directory default-dir))
+ (fn (read-file-name Save to:  ddir nil nil filename))
+ (efn (expand-file-name fn))
+ (dir (file-name-directory efn)))
+(when (not (file-accessible-directory-p dir))
+  (when (y-or-n-p (concat Create directory  dir  ))
+(make-directory dir t)))
+(if (file-accessible-directory-p dir)
+(setq savepath fn)
+  (setq default-dir (file-name-directory fn)
+savepath))
+
+(defun notmuch-save-attachment (mm-handle default-dir)
+  Save the current attachment part to a file.
+  (cond ((not (notmuch-attachment-q mm-handle))
+ (message Current part is not an attachment.)
+ nil)
+(t
+ (let* ((fn (cdr (assq 'filename (mm-handle-disposition mm-handle
+(savepath (notmuch-get-save-path fn default-dir)))
+   (mm-save-part-to-file mm-handle savepath)
+   savepath
+
+(defun notmuch-save-attachment-num (mm-handle part-num)
+  Save the nth part number
+  (let ((nfound 0)
+(nsaved 0))
+(notmuch-foreach-mime-part
+ (lambda (p)
+   (when (notmuch-attachment-q p)
+ (cond ((equal (+ 1 nfound) part-num)
+(when (notmuch-save-attachment p notmuch-default-save-dir)
+  (incf nsaved
+ (incf nfound))) mm-handle)
+(equal nsaved 1)))
+
+(defun notmuch-show-save-attachment (num)
+  Save a single attachment.
+  (interactive p)
   (with-current-notmuch-show-message
(let ((mm-handle (mm-dissect-buffer)))
- (notmuch-save-attachments
-  mm-handle ( (notmuch-count-attachments mm-handle) 1
-  (message Done))
+ (if (notmuch-save-attachment-num mm-handle num)
+ (message Attachment %d saved. num)
+   (message Failed to save attachment.)
+
+(defun notmuch-show-save-all-attachments ()
+  Save all attachments of a message to a directory.
+  (interactive)
+  (with-current-notmuch-show-message
+   (let ((nfound 0)
+ (nsaved 0)
+ (default-dir notmuch-default-save-dir)
+ (mm-handle (mm-dissect-buffer)))
+ (notmuch-foreach-mime-part
+  (lambda (p)
+(when (notmuch-attachment-q p)
+  (incf nfound)
+  (let ((savepath 

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

2009-12-14 Thread Carl Worth
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!

 However, support for deletion is important to me. Here is a first patch
 that implements it for the emacs interface.

Thanks for the contribution. I'll queue this and review it soon. You'll
notice my review-and-merge pattern is very bursty, and I happen to be
between bursts at the moment.

(Of course, others can review too---I'm much more likely to merge code
if it has one or two Reviewed-By comments on the list.)

 I also added a command history to notmuch-search.

That sounds very nice! I'll steal that for command history for '|' which
I've been needing for a while.

 Now I'd like to write a command to expunge deleted mails; this shouldn't
 be difficult. Having notmuch detect that some mails disappeared and
 update the database seems more difficult, though.

That part I'll be doing. It's already on my TODO list and very highly
prioritized.

 PS: I have trouble understanding why space on the last message on a
 thread deletes the inbox tag. If you do it, then you mail becomes
 untagged and imo quite difficult to search. How is the mail flow
 supposed to work?

I've discussed previously that I plan to remove this behavior from the
function bound to space. Instead, it will require an explicit action to
archive a thread, ('a' to archive and advance to the next thread, and
'x' to archive and exit back to the search results).

-Carl


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


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

2009-12-14 Thread Carl Worth
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 with emacs23, so I decided to play with json a bit.

That sounds very promising. I wasn't aware this existed inside emacs
already.

 I settled on the jansson library (http://www.digip.org/jansson/)
 because it seemed to have a sane api and documentation, but there are
 many choices.  I'll follow up with the actual patch, but the idea is to
 replace the printfs in show_message with calls to set (key,value) pairs
 in a json object, and output it at the end.

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 should at least look at how easy it would be to just emit
the syntax manually.

 So, do people think this is a reasonable idea to persue?

I do, yes. The current lack of full quoting is an obnoxious bug.

 1) it adds a dependency, but not a heavy one. jansson is about 300k
 installed on debian/i386

That might be acceptable. And we might rewrite the patch to avoid it as
well. I'd like to see what that would take.

 2) It might mean that people using emacs22 might have to score
 json.el from somewhere; I'm not sure.

Currently, it sounds like notmuch is entirely unusable from emacs22, so
I'm really not too concerned about one more thing that requires emacs
23.

 3) There is some increase in memory use since the whole thread has
 to be built as a json object before being output.

Right. That would be another reason to just stream the output
manually. The syntax doesn't require things like knowing the size of an
array before emitting the first element, right?

 4) Of course jansson is doing it's own reference counting memory
 managment, and not using talloc. But we already have glib...

It's not evil to not use talloc. So not an issue there.

-Carl


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


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

2009-12-14 Thread Carl Worth
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 didn't remember seeing the
actual patch? Did I miss it? I also didn't find it again when searching
and re-reading the thread. hopefully this isn't a case of my mail
client's search feature failing me... ;-)

 Is it worth updating to HEAD and trying again?

If you'd like to, please feel free. I'd be glad to evaluate different
options here.

-Carl


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


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

2009-12-14 Thread Carl Worth
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 code there are, from the point of keeping up with
 security problems.  This is probably a bias I picked up from Debian.

Embedded copies of code already packaged in Debian is something to
avoid, definitely. I'm not actively against having dependencies for
functionality that makes sense.

For example, the current libsha1 code in notmuch has been the subject of
a debate about embedded code copies here on the list already. If
somebody would like to maintain that code as a Debian package, then I
would be happy to depend on it that way rather than having an embedded
copy inside notmuch.

For something like JSON output, I really can't see how we need an
external library. The job we're talking about is changing our current
delimiters and then fixing our code to properly quote delimiters
appearing in the content. That doesn't sound like a job that needs a
library.

(Meanwhile, if we were parsing JSON, then I'd be happy to depend on a
library for that.)

-Carl


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


Re: [notmuch] Rework of attachment saving

2009-12-14 Thread Carl Worth
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 buttons.  That would certainly be nice to have
 however and I belive this change should make it easy for someone who
 knows how buttons work to implement it.

Excellent, Keith!

I'm just writing to say thanks for now, and I will review the patch in
more detail later.

-Carl



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


[notmuch] [patch] store folder information

2009-12-14 Thread Andreas Klöckner
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: Andreas Kloeckner inf...@tiker.net
Date: Mon, 14 Dec 2009 14:16:20 -0500
Subject: [PATCH] Preseve folder information when indexing.

---
 lib/database.cc |   14 +-
 lib/index.cc|2 ++
 lib/notmuch.h   |1 +
 notmuch-new.c   |   35 ++-
 4 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index b6c4d07..e6b4272 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -70,10 +70,9 @@ typedef struct {
  *
  *	MESSAGE_ID:	The unique ID of the mail mess (see id above)
  *
- * In addition, terms from the content of the message are added with
- * from, to, attachment, and subject prefixes for use by the
- * user in searching. But the database doesn't really care itself
- * about any of these.
+ * In addition, terms from the content of the message are added with from,
+ * to, attachment, subject, and folder prefixes for use by the user in
+ * searching. But the database doesn't really care itself about any of these.
  *
  * Timestamp document
  * --
@@ -124,7 +123,8 @@ prefix_t PROBABILISTIC_PREFIX[]= {
 { from, XFROM },
 { to, XTO },
 { attachment, XATTACHMENT },
-{ subject, XSUBJECT}
+{ subject, XSUBJECT},
+{ folder, XFOLDER}
 };
 
 int
@@ -889,6 +889,7 @@ _notmuch_database_link_message (notmuch_database_t *notmuch,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *notmuch,
 			  const char *filename,
+			  const char *folder_name,
 			  notmuch_message_t **message_ret)
 {
 notmuch_message_file_t *message_file;
@@ -1006,6 +1007,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
 
 	_notmuch_message_index_file (message, filename);
 
+if (folder_name != NULL)
+_notmuch_message_gen_terms (message, folder, folder_name);
+
 	_notmuch_message_sync (message);
 } catch (const Xapian::Error error) {
 	fprintf (stderr, A Xapian exception occurred adding message: %s.\n,
diff --git a/lib/index.cc b/lib/index.cc
index 125fa6c..55f3fbc 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
 	s++;
 	if (strncasecmp (s, re:, 3) == 0)
 	s += 3;
+else if (strncasecmp (s, aw:, 3) == 0)
+	s += 3;
 	else
 	break;
 }
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 60834fb..5d3b3c6 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -265,6 +265,7 @@ notmuch_database_get_timestamp (notmuch_database_t *database,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *database,
 			  const char *filename,
+			  const char *folder_name,
 			  notmuch_message_t **message);
 
 /* Find a message with the given message_id.
diff --git a/notmuch-new.c b/notmuch-new.c
index 9d20616..bc8adc8 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,7 @@
 #include notmuch-client.h
 
 #include unistd.h
+#include glib.h
 
 static volatile sig_atomic_t do_add_files_print_progress = 0;
 
@@ -144,6 +145,34 @@ add_files_recursive (notmuch_database_t *notmuch,
 struct dirent **namelist = NULL;
 int num_entries;
 
+gchar *full_folder_name = NULL;
+gchar *folder_base_name = NULL;
+
+/* Find name of folder containing the email. */
+full_folder_name = g_strdup(path);
+while (1)
+{
+folder_base_name = g_path_get_basename(full_folder_name);
+
+if (strcmp(folder_base_name, cur) == 0
+|| strcmp(folder_base_name, new) == 0)
+{
+gchar *parent_name = g_path_get_dirname(full_folder_name);
+g_free(full_folder_name);
+full_folder_name = parent_name;
+}
+else
+break;
+}
+
+g_free(full_folder_name);
+
+if (strcmp(folder_base_name, .) == 0)
+{
+g_free(folder_base_name);
+folder_base_name = NULL;
+}
+
 /* If we're told to, we bail out on encountering a read-only
  * directory, (with this being a clear clue from the user to
  * Notmuch that new mail won't be arriving there and we need not
@@ -235,7 +264,9 @@ add_files_recursive (notmuch_database_t *notmuch,
 		fflush (stdout);
 		}
 
-		status = notmuch_database_add_message (notmuch, next, message);
+		status = notmuch_database_add_message (notmuch, next, 
+   folder_base_name, 
+   message);
 		switch (status) {
 		/* success */
 		case NOTMUCH_STATUS_SUCCESS:
@@ -301,6 +332,8 @@ add_files_recursive (notmuch_database_t *notmuch,
 	closedir (dir);
 if (namelist)
 	free (namelist);
+if (folder_base_name)
+

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

2009-12-14 Thread David Bremner
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 think we should at least look at how easy it would be to just emit
 the syntax manually.

OK, I'll wait for Scott's patch, and see how he is using cJSON. Just
stealing a few functions might be the way to go.

The cJSON code is less horrifying after running through indent. Now all
we need is indent --carl :)

d

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