[notmuch] [PATCH] Refactor notmuch-folder-add to avoid recursion. Allow notmuch-folders to contain folders with empty search criteria.

2010-02-24 Thread James Vasile
Refactor notmuch-folder-add to avoid recursion.  Allow notmuch-folders
to contain folders with empty search criteria.

Setting a folder's search criteria to "" in notmuch-folders causes a
label to be printed in notmuch-folder view.  This is good for helping
organizing folders, e.g. by using ("Mailing lists" . "").

The old, recursive version ran the risk of exceeding
max-lisp-eval-depth.
---
 notmuch.el |   36 +---
 1 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6482170..5eb6bd1 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1699,21 +1699,27 @@ Currently available key bindings:
   (notmuch-folder))

 (defun notmuch-folder-add (folders)
-  (if folders
-  (let* ((name (car (car folders)))
-   (inhibit-read-only t)
-   (search (cdr (car folders)))
-   (count (notmuch-folder-count search)))
-   (if (or notmuch-folder-show-empty
-   (not (equal count "0")))
-   (progn
- (insert name)
- (indent-to 16 1)
- (insert count)
- (insert "\n")
- )
- )
-   (notmuch-folder-add (cdr folders)
+  (mapc
+   (lambda (folder)
+ (let ((name (car folder)))
+   (if (not (string= "" (cdr folder)))
+  (let* ((inhibit-read-only t)
+ (search (cdr folder))
+ (count (notmuch-folder-count search)))
+(if (or notmuch-folder-show-empty
+(not (equal count "0")))
+(progn
+  (insert name)
+  (indent-to 16 1)
+  (insert (notmuch-folder-count (format "(%s) and tag:unread" 
search)))
+  (insert "/")
+  (insert count)
+  (insert "\n"
+  (progn
+(insert "\n")
+(insert name)
+(insert "\n")
+   folders))

 (defun notmuch-folder-find-name ()
   (save-excursion
-- 
1.6.3.3



[notmuch] patchwork test instance

2010-02-24 Thread martin f krafft
also sprach Carl Worth  [2010.02.24.2010 +0100]:
> > Carl, would you consider bouncing messages to addresses like
> > patchwork+rejected at patchwork.notmuchmail.org? That would make it
> > trivial for me to write glue to update patchwork automatically.
> 
> Now you're talking my language, Martin!
> 
> I'm disinclined to go to a web browser, find the right buttons and
> push them, but it's easy for me to add an extra address when
> declining a patch, (since I have to write that email message
> already and I can even just add a keybinding to add the extra
> address).

This is trivial to implement, but I don't see myself able to do that
anytime soon. The basic idea is the same as the Git hook[0], and if
someone wanted to take a shot, I'd be happy to create an account on
the machine hosting the patchwork instance.

0. http://lists.ozlabs.org/pipermail/patchwork/2010-February/000224.html

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"most people become bankrupt through having invested too heavily in
 the prose of life. to have ruined one's self over poetry is an
 honour."
-- oscar wilde

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100224/bad0293c/attachment.pgp>


[notmuch] loss of duplicate messages

2010-02-24 Thread Jameson Rollins
Hi, folks.  I'm continuing to find it problematic that duplicate
messages are only appearing to be indexed once.  I'm wondering what are
the possbile solutions to this issue, if any.

For instance, I sent a message that was bcc'd to a long list of people,
including myself.  All of my sent mail is fcc'd to a local directory.
The index of my original sent message was almost immediately trumped by
the index of the message I then recieved back through the mail.  Since
the recieved message trumped the fcc'd message, I had a difficult time
finding the bcc list, since I had to go outside of notmuch.

Is there no way to make it possible to have notmuch returns all copies
of messages matching searches?  I don't think this happens frequently,
so I don't think it would get in the way, but it's certainly useful for
me to have it.

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/20100224/dbdfa481/attachment.pgp>


[notmuch] JSON output as default [was: Re: [PATCH] Add an "--output=(json|text|)" command-line option...]

2010-02-24 Thread ra...@free.fr

> > I definitely want to be able to pipe single-field lists coming from
> > notmuch to grep, xargs, shell for loops, etc. without having to
> decode
> > JSON.
> 
> While I would love to see JSON (even by default), I agree. If I just
> want to code up a notmuch-based address book with sth like:
> 
> notmuch show to:Diana --output=to --sort=relevance --limit=20
> 
> just getting back a plain list of mail addresses is the easiest to
> handle.

This would also be useful for the Emacs/Vim interfaces. For instance, my smart 
completion patch
would really benefit from notmuch being capable of outputing various fields in 
all messages in plain text
separated by newlines (this is even easier to handle in emacs code than JSON). 
In fact, most of the C code I had
to write for this patch is better replaced by the --output option...


[notmuch] envelope-to

2010-02-24 Thread James Vasile
Can notmuch search for envelope-to:?  Or for that matter, can it
search for arbitrary headers?

I get a lot of BCC mail.  The envelope-to is a good way for me to know
which of my various addresses was BCC'd.

Thanks.


[notmuch] JSON output as default [was: Re: [PATCH] Add an "--output=(json|text|)" command-line option...]

2010-02-24 Thread Sebastian Spaeth
> I definitely want to be able to pipe single-field lists coming from
> notmuch to grep, xargs, shell for loops, etc. without having to decode
> JSON.

While I would love to see JSON (even by default), I agree. If I just
want to code up a notmuch-based address book with sth like:

notmuch show to:Diana --output=to --sort=relevance --limit=20

just getting back a plain list of mail addresses is the easiest to handle.


[notmuch] [PATCH] add notmuch-show-delete keybinding 'd'

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 11:28:29 -0800, Carl Worth  wrote:
> On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins  finestructure.net> wrote:
> > > 2. It removes the "inbox" and "unread" tags while adding the tag to
> > >indicate deletion.
> > 
> > Hey, Carl.  Why is this last point important?
> 
> I guess I was imagining the case of running "notmuch search tag:inbox"
> at the command-line. That output will get out of hand fairly quickly if
> it includes all deleted messages back to the beginning of time, (or as
> far back as the window of actually deleting files from the
> mailstore[*]).
> 
> But you're right that tags should really be handled orthogonally. Maybe
> what we want is lower-level support for the "deleted" tag? Other than
> just the high-level emacs interface?

Yeah, I tend to think that notmuch should be as agnostic about tag
handling as possible.  The beauty of that is that it keeps things as
simple and configurable as possible, which is necessary because everyone
will have a different way they want to do things.

The point of the functions provided by these patches is basically just
convenience.  In fact, I had implemented the functions I previously
included in my own private .el, since I didn't know if they would be
wanted by all others.  In general, I'm a big fan of "keep it simple"
(KIS).  In this case that means "if I want to add a delete tag, the tool
should do just that and nothing else".  I certainly don't want the other
tags modified.  If one did, it's really quite easy to write custom emacs
functions to do that.  We can just hints on doing that in the wiki if
need be.

> That could put *more* direct interpretation of specific tags in the low
> levels. And this is the opposite direction of where we've been going (or
> talking about at least). We've currently got "inbox" and "unread" inside
> the low levels and there's been talking or removing those, switching to
> just "new" or making it all configurable.

This isn't a bad idea at all.  I don't think it changes the
functionality much, but it does make things conceptually much simpler,
which I'm always in favor of (KIS).

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/20100224/f6ad47ab/attachment.pgp>


[notmuch] [PATCH] notmuch.el: hide original message in top posted replies.

2010-02-24 Thread da...@tethera.net
From: David Bremner 

This code treats top posted copies essentially like signatures, except
that it doesn't sanity check their length, since neither do their
senders.

In an unrelated cleanup, remove the let definition of sig-end, since
it was unused.

New user-visible variable:

  notmuch-show-original-button-format:   Allow customization of button text.
---

This is the unsquashed version of what was new in the v3 of the
citation patch, rebased against current master.

 notmuch.el |   40 
 1 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6482170..b1a590f 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -107,9 +107,15 @@
 The regexp can (and should) include $ to match the end of the
 line, but should not include ^ to match the beginning of the
 line. This is because notmuch may have inserted additional space
-for indentation at the beginning of the line. But notmuch will
-move past the indentation when testing this pattern, (so that the
-pattern can still test against the entire line).")
+for indentation at the beginning of the line.")
+
+(defvar notmuch-show-original-regexp "\\(--+\s?[oO]riginal 
[mM]essage\s?--+\\)$"
+  "Pattern to match a line that separates original message from reply in 
top-posted message.
+
+The regexp can (and should) include $ to match the end of the
+line, but should not include ^ to match the beginning of the
+line. This is because notmuch may have inserted additional space
+for indentation at the beginning of the line.")

 (defvar notmuch-show-signature-button-format
   "[ %d-line signature. Click/Enter to toggle visibility. ]"
@@ -123,6 +129,13 @@ Can use up to one integer format parameter, i.e. %d")

 Can use up to one integer format parameter, i.e. %d")

+(defvar notmuch-show-original-button-format 
+  "[ %d-line hidden original message. Click/Enter to show ]"
+  "String used to construct button text for hidden copies of messages
+
+Can use up to one integer format parameter, i.e. %d")
+
+
 (defvar notmuch-show-signature-lines-max 12
   "Maximum length of signature that will be hidden by default.")

@@ -717,6 +730,9 @@ which this thread was originally shown."
   :supertype 'notmuch-button-invisibility-toggle-type)
 (define-button-type 'notmuch-button-signature-toggle-type 'help-echo "mouse-1, 
RET: Show signature"
   :supertype 'notmuch-button-invisibility-toggle-type)
+(define-button-type 'notmuch-button-original-toggle-type 'help-echo "mouse-1, 
RET: Show original message"
+  :supertype 'notmuch-button-invisibility-toggle-type)
+
 (define-button-type 'notmuch-button-headers-toggle-type 'help-echo "mouse-1, 
RET: Show headers"
   :supertype 'notmuch-button-invisibility-toggle-type)
 (define-button-type 'notmuch-button-body-toggle-type
@@ -768,9 +784,25 @@ is what to put on the button."
   (let ((citation-regexp (notmuch-show-citation-regexp depth))
(signature-regexp (concat (format "^[[:space:]]\\{%d\\}" depth)
  notmuch-show-signature-regexp))
+   (original-regexp (concat (format "^[[:space:]]\\{%d\\}" depth) 
+ notmuch-show-original-regexp))
+
(indent (concat "\n" (make-string depth ? 
 (goto-char beg)
 (beginning-of-line)
+
+(if (and (< (point) end) 
+(re-search-forward original-regexp end t))
+   (let* ((msg-start (match-beginning 0))
+  (msg-lines (1- (count-lines msg-start end
+ (notmuch-show-region-to-button 
+  msg-start
+  end
+  "original"
+  indent
+  (format notmuch-show-original-button-format msg-lines)
+  )))
+
 (while (and (< (point) end)
(re-search-forward citation-regexp end t))
   (let* ((cite-start (match-beginning 0))
@@ -786,10 +818,10 @@ is what to put on the button."
   (format notmuch-show-citation-button-format
   (- cite-lines notmuch-show-citation-lines-prefix))
   
+
 (if (and (< (point) end)
 (re-search-forward signature-regexp end t))
(let* ((sig-start (match-beginning 0))
-  (sig-end (match-end 0))
   (sig-lines (1- (count-lines sig-start end
  (if (<= sig-lines notmuch-show-signature-lines-max)
  (notmuch-show-region-to-button
-- 
1.6.6



[notmuch] [PATCH] Calls to notmuch get queued and executed asynchronously.

2010-02-24 Thread James Vasile
Sleep between retrying asynchronous notmuch commands and check for
notmuch-process before firing off a new one

If the db is locked when notmuch tries to write to it, an error is
reported to the client (in this case, notmuch.el).  Instead of
accepting that error, wait a small amount of time and then try again.

Also, don't start multiple asynchronous processes.
---
 notmuch.el |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 7fc63e9..31e89b9 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1402,9 +1402,14 @@ args is a list of arguments to notmuch.  ex: (\"tag\" 
\"+list\"

 Calls to notmuch are queued and called asynchronously."
   (setq notmuch-asynch-queue (append notmuch-asynch-queue (list args)))
-  (when (= (length notmuch-asynch-queue) 1)
+  (when (and (= (length notmuch-asynch-queue) 1)
+(not (get-process "notmuch-process")))
 (apply 'notmuch-call-notmuch-process-asynch (pop notmuch-asynch-queue
-  
+
+(defun notmuch-asynch-sleep-sentinel (process event)
+  "After we sleep, try a command from the notmuch queue"
+  (apply 'notmuch-call-notmuch-process-asynch (pop notmuch-asynch-queue)))
+
 (defun notmuch-call-notmuch-process-asynch-sentinel (process event)
   "Handle the exit of a notmuch asynch process.

@@ -1416,11 +1421,16 @@ command, try it again."
 (if (= (process-exit-status process) 0)
(kill-buffer (buffer-name (process-buffer process)))
(if (search-forward "Unable to acquire database write lock" nil t)
-   (apply 'notmuch-call-notmuch-process-asynch (cdr (process-command 
process)))
+   (progn
+ (push (cdr (process-command process)) notmuch-asynch-queue)
+ (set-process-sentinel 
+  (start-process "notmuch-sleep" nil "sleep" "3")
+  'notmuch-asynch-sleep-sentinel))
(error (format "%s: %s" (join-string-list (process-command process))
   (buffer-string))
   (apply 'notmuch-call-notmuch-process-asynch (pop notmuch-asynch-queue)))

+
 (defun notmuch-call-notmuch-process ( args)
   "Synchronously invoke \"notmuch\" with the given list of arguments.

-- 
1.6.3.3



[notmuch] [PATCH] Simplify "unread" tag handling in emacs UI.

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 10:26:47 -0800, Carl Worth  wrote:
> On Wed, 17 Feb 2010 14:33:11 +0100, "Sebastian Spaeth"  SSpaeth.de> wrote:
> > On Tue, 19 Jan 2010 17:54:16 -0500, Jameson Rollins  > finestructure.net> wrote:
> > > This patch is intended to greatly simplify the handling of the
> > > "unread" tag in the emacs UI.  This patch adds a new function
> > > 'notmuch-show-mark-read', that removes the "unread" tag in
> > > notmuch-show-mode.  This function is then executed as a
> > > notmuch-show-hook, and by notmuch-show-next-message.  All of the
> > > functions that explicitly marked messages as unread are removed or
> > > renamed.

> Thanks for contributing the patch. This exact feature, (removing all
> commands with "and mark read" in their names), has been on my todo list
> for too long, and I'm anxious to remove it from that. But...
>
> > It then checks the unread status in order to decide whether to proceed
> > to the next again. So with your patch notmuch-show-next-unread-message
> > will skip through all messages in a thread thinking they are all read
> > (and actually marking all as read).
> 
> ...that seems like a fatal bug in this script. Thanks for noting that
> Sebastian.

I certainly don't see it as fatal, but it is something we should
resolve.  I think the simplification that the patch provides is worth
it.

I'm seeing the notmuch-show-next-unread-message as a non-interactive
function that's not currently called by any other functions, and is
therefore not being used.  Sebastian, are you using that in a private
function, or am I misreading the code?

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/20100224/c659445a/attachment-0001.pgp>


[notmuch] [PATCH] add notmuch-show-delete keybinding 'd'

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 10:53:50 -0800, Carl Worth  wrote:
> But this patch does have two good ideas not in the other patch, (both of
> which I mentioned in the review):
> 
> 1. It adds a keybinding to the notmuch-show mode
> 
> 2. It removes the "inbox" and "unread" tags while adding the tag to
>indicate deletion.

Hey, Carl.  Why is this last point important?  I've been using my own
patchs for handling deleted messages, and all deleting a message or
thread does is add the "delete" tag.  Why should it modify any other
tags?  A message/thread should be allowed to be both deleted and in the
inbox.

As for "unread", I think that should be handled by actually reading the
message, not by manually applying a state to it.

FWIW, below are the functions I've added to my notmuch .el to handle
message/thread deleting.

jamie.

(defun notmuch-search-delete-thread ()
  "Delete thread (add \"delete\" tag).

This function advances the next thread when finished."
  (interactive)
  (notmuch-search-add-tag "delete")
  (forward-line))

(define-key notmuch-search-mode-map "d" 'notmuch-search-delete-thread)

(defun notmuch-show-delete-message ()
  "Delete message (add \"delete\" tag).

Add the \"delete\" tag to message. Then kill this buffer and
show the next thread from the search from which this thread was
originally shown."
  (interactive)
  (notmuch-show-add-tag "delete")
  (let ((parent-buffer notmuch-show-parent-buffer))
(kill-this-buffer)
(if parent-buffer
(progn
  (switch-to-buffer parent-buffer)
  (forward-line)

(define-key notmuch-show-mode-map "d" 'notmuch-show-delete-message)
-- 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/20100224/7ec5f864/attachment.pgp>


[notmuch] Introducing notmuchsync

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth  wrote:
> Elsewhere in the thread Jameson Rollins wrote:
> > I should have mentioned in my previous mail that I think this tool is
> > a great idea, and I plan on using it.  I just hope that all of it's
> > functionality will be integrated directly into notmuch itself.
> 
> I think that's the open question still. How much of this kind of
> functionality do we integrate into notmuch itself. I don't know the
> answer to that question yet, but I'm quite happy to see people
> experimenting with doing scripts like this on top of notmuch already.
> 
> I do know that I want to do thing to make such scripting easier,
> (independent of whether the current functionality gets folded into
> notmuch).

Hey, Carl.  Yeah, this was an old post and there's been lots of
discussion about it.  I'm certainly more flexible about my position now
than I think I was originally.

In fact, I actually gave up on syncing notmuch and maildir, and am
basically punting on maildir altogether.  This is slightly problematic
because notmuch is still missing some key features so I occasionally
have to use other mailers to achieve certain things (especially OpenPGP
stuff).  I worry about it down the line as well, if I ever have to use
another mailer for any reason.  All mail I've received since my switch
to notmuch will show up as "unread" in maildir readers.

I think notmuch wrapper scripts like notmuchsync are going to be crucial
for notmuch down the line, so I definitely agree that doing everything
possible to make it easier for them is a very good thing.  I am using
notmuchsync for deleting "delete" tagged messages, for which it's very
useful.  It's pretty slow, though, which I've been chalking up to the
fact that it has to parse the notmuch "show" output.  Once notmuch can
output just the paths to messages matching search results that should
get much much faster.

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/20100224/a622b600/attachment.pgp>


[notmuch] [PATCH] add notmuch-show-delete keybinding 'd'

2010-02-24 Thread Carl Worth
On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins  wrote:
> > 2. It removes the "inbox" and "unread" tags while adding the tag to
> >indicate deletion.
> 
> Hey, Carl.  Why is this last point important?

I guess I was imagining the case of running "notmuch search tag:inbox"
at the command-line. That output will get out of hand fairly quickly if
it includes all deleted messages back to the beginning of time, (or as
far back as the window of actually deleting files from the
mailstore[*]).

But you're right that tags should really be handled orthogonally. Maybe
what we want is lower-level support for the "deleted" tag? Other than
just the high-level emacs interface?

That could put *more* direct interpretation of specific tags in the low
levels. And this is the opposite direction of where we've been going (or
talking about at least). We've currently got "inbox" and "unread" inside
the low levels and there's been talking or removing those, switching to
just "new" or making it all configurable.

I do know that I also want to have low-level support for "muted" (aka
"killed" threads). For that I want an --exclude option to notmuch search
that would look something like this:

notmuch search --exclude="" 

Where the result would be the set difference of the threads matched by
the two sets of search terms. Perhaps with something like that in place
all we'd want in addition would be a configuration option to add
--exclude=tag:muted by default. And if we go that route, perhaps we
could have an option for an implicit "and not tag:deleted" for the
search terms as well.

I do worry about making the command-line tool hard to use without a
configuration file, but it also seems very appealing to keep the lowest
levels very general to allow people to experiment with whatever they
want on top.

-Carl

[*] My eventual plan for detected spam and manually deleted messages is
to keep them in the mail store so they are searchable for some time (a
month or two) and then deleting them after that (with something like a
cron job using a convenient --before="2 months ago" syntax to a notmuch
search command).
-- 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/20100224/5a4864e5/attachment.pgp>


[notmuch] Git feature branch

2010-02-24 Thread Carl Worth
On Wed, 03 Feb 2010 22:58:05 -0500, Jameson Rollins  wrote:
> Once the project becomes more mature and other developers are
> vetting patches, then their branches can take over as "master" in the
> absence of an outdated canonical master.

The other thing that will happen as the project matures is that I expect
to start merging other people's carefully vetted and reviewed
branches. This will happen as people start to take ownership of
particular code areas and we establish mutual trust on taste, code
review, testing, etc.

I think that will be the real solution for future bottlenecks when I'm
not available for much patch review due to travel, sickness,
hectic-life-in-general, etc.

-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/20100224/59f381ce/attachment.pgp>


[notmuch] patchwork test instance

2010-02-24 Thread Carl Worth
On Thu, 11 Feb 2010 11:22:16 +1300, martin f krafft  
wrote:
> Carl, would you consider bouncing messages to addresses like
> patchwork+rejected at patchwork.notmuchmail.org? That would make it
> trivial for me to write glue to update patchwork automatically.

Now you're talking my language, Martin!

I'm disinclined to go to a web browser, find the right buttons and push
them, but it's easy for me to add an extra address when declining a
patch, (since I have to write that email message already and I can even
just add a keybinding to add the extra address).

-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/20100224/30172a2d/attachment.pgp>


[notmuch] patchwork test instance

2010-02-24 Thread Carl Worth
On Wed, 10 Feb 2010 10:25:49 +0100, "Sebastian Spaeth"  wrote:
> On Wed, 10 Feb 2010 16:25:03 +1300, martin f krafft  
> wrote:
> > > http://patchwork.madduck.net/project/notmuch/list/ now exists.

And even as http://patchwork.notmuchmail.org now.

> As long as patches aren't being marked as "rejected" or "superseded", I
> don't think it will be that useful in the long run. If it were actually
> maintained by a few people, this would probably be different.

I agree that in its current form it's not useful, (it seems to be just a
long list of the patches that have ever been submitted).

I seem to recall Martin saying that patches that get accepted will be
automatically detected and removed from the list. Is that successfully
happening now?

> The alternative I can see is that we create a web page of patches based
> on carls notmuch tags (the tagging scheme he uses is unknown to me
> though).

At this point, and with the JSON support in place, I think it should be
trivial for someone to write a script that will take a notmuch search
specification and create an HTML view of all the threads matching that
search, right? If so, I'd be happy to regularly post the results of my
notmuch todo list, which, by the way, is currently:

notmuch search tag:todo-notmuch or (tag:notmuch and (tag:todo or tag:inbox))

In the meantime, if someone does want to push some buttons in patchwork,
nothing before 2009-12-01 at least is interesting.

-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/20100224/7a2c0f74/attachment.pgp>


[notmuch] Git feature branch

2010-02-24 Thread Carl Worth
On Wed, 27 Jan 2010 14:17:39 -0500, Ben Gamari  wrote:
> I agree. There is no good reason to switch away from the existing
> infrastructure. If he wants, Carl can give regular contributors their
> own repositories on notmuchmail.org if some people have difficulties
> providing it themselves. After all, this is one of the strengths of
> distributed version control.

I should emphasize that point:

I think it's great that people are posting their own notmuch
repositories wherever they see fit. Please continue doing that.

Also, if anybody would like to host such a repository on the
notmuchmail.org server, I'm more than happy to arrange that. Just let me
know.

-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/20100224/84f16445/attachment.pgp>


[notmuch] [PATCH] add notmuch-show-delete keybinding 'd'

2010-02-24 Thread Carl Worth
On Wed, 20 Jan 2010 11:56:07 +0100 (CET), racin at free.fr wrote:
> I posted a similar patch a while ago, that also did not show deleted
> messages by default. Don't know if Carl wants to integrate this though

OK. When two people are independently contributing similar
functionality, it's more than clear that I'm far too behind on patch
review.

Matthieu, I've just posted my review of your original patch. I think I
like the name "deleted" for the tag rather than "delete", (it's
consistent with "unread" at least that way). And I like the support for
excluding deleted results in that patch as well.

But this patch does have two good ideas not in the other patch, (both of
which I mentioned in the review):

1. It adds a keybinding to the notmuch-show mode

2. It removes the "inbox" and "unread" tags while adding the tag to
   indicate deletion.

-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/20100224/1ea81a0f/attachment.pgp>


[notmuch] [PATCH] Support for deletion (patch included)

2010-02-24 Thread Carl Worth
On Sun, 13 Dec 2009 12:54:09 +0100, Matthieu Lemerre  wrote:
> I forgot the attachment..

Hi Matthieu,

This is a very interesting patch. Thanks for contributing it.

Could you also write a commit message describing what the patch does?
The easiest way for me to apply that would be if you would create a git
commit, then run "git format-patch origin/master" and mail the resulting
files, (the "git send-email" command can be used here, or you can insert
the files into a mail-composition buffer and modify them as needed).

A couple of minor comments on the patch:

>  (define-key map "a" 'notmuch-search-archive-thread)
> +(define-key map "d" 'notmuch-search-mark-as-deleted)

For consistency, let's name this notmuch-search-delete-thread.

And we'll probably want a notmuch-show-delete-message function as well,
no?

> +(defvar notmuch-search-history nil)

Excellent! I've wanted custom search history for a while, and just
didn't know how to do it with (interactive "s"). It looks easy enough
with read-string as you're doing here. But this is independent
functionality, so would be preferred as an independent patch/commit.

>(forward-line))
>  
> +
> +(defun notmuch-search-mark-as-deleted ()
> +  "Mark the currently selected thread as deleted (set its \"deleted\" tag).
> +This function advances the next thread when finished."
> +  (interactive)
> +  (notmuch-search-add-tag "deleted")
> +  (forward-line))
> +
> +
>  (defun notmuch-search-process-sentinel (proc msg)

Watch that extra whitespace. The convention is a single line of
whitespace between each function.

And should we also archive the thread before removing the deleted tag?

> +With prefix argument, include deleted items.

That's a pretty good interface I think.

Another approach would be to do something like what sup does---that
would be to scan the search terms and if it contains "tag:deleted" and
all then don't prepend the "not tag:deleted and" to the search
string. The assumption there is that if the user is explicitly
mentioning the deleted tag, then we should just rely on the user to
explicitly describe how the tag should be treated.

That's perhaps not an unreasonable heuristic, and might be done even in
addition to the prefix-argument approach. But that could be an
additional commit, and I won't require it.

> +  (interactive (let* ((prefix current-prefix-arg)
> +   (query (if prefix
> +  (read-string "Notmuch search (including 
> deleted): "
> +   notmuch-search-query-string
> +   'notmuch-search-history)
> +(read-string "Notmuch search: " nil
> + 'notmuch-search-history

Why is the second (initial-input) argument non-nil in one case, but nil
in the other? The documentation for `read-string' says the argument is
deprecated and should be nil in all new code.

> +  (list query nil prefix)))
> +  (let ((real-query (if include-deleted query 
> +   (concat "not tag:deleted and (" query ")")))
> + (buffer (get-buffer-create (concat "*notmuch-search-" query
> "*"

Does the include-deleted case actually work? I don't see anything in the
code that sets this variable. (I'm just reviewing here--I haven't tested
it manually).

> @@ -1351,7 +1374,6 @@ search."
>  
>  Runs a new search matching only messages that match both the
>  current search results AND the additional query string provided."
> -  (interactive "sFilter search: ")
>(let ((grouped-query (if (string-match-p notmuch-search-disjunctive-regexp 
> query) (concat "( " query " )") query)))
>  (notmuch-search (concat notmuch-search-query-string " and " 
> grouped-query) notmuch-search-oldest-first)))

Is this just an accidental chunk in the patch? I don't see why this
function should become non-interactive now.

Thanks again,

-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/20100224/4de3a53e/attachment-0001.pgp>


[notmuch] [PATCH] Simplify "unread" tag handling in emacs UI.

2010-02-24 Thread Carl Worth
On Wed, 17 Feb 2010 14:33:11 +0100, "Sebastian Spaeth"  wrote:
> On Tue, 19 Jan 2010 17:54:16 -0500, Jameson Rollins  finestructure.net> wrote:
> > This patch is intended to greatly simplify the handling of the
> > "unread" tag in the emacs UI.  This patch adds a new function
> > 'notmuch-show-mark-read', that removes the "unread" tag in
> > notmuch-show-mode.  This function is then executed as a
> > notmuch-show-hook, and by notmuch-show-next-message.  All of the
> > functions that explicitly marked messages as unread are removed or
> > renamed.

Hi Jameson,

Thanks for contributing the patch. This exact feature, (removing all
commands with "and mark read" in their names), has been on my todo list
for too long, and I'm anxious to remove it from that. But...

> It then checks the unread status in order to decide whether to proceed
> to the next again. So with your patch notmuch-show-next-unread-message
> will skip through all messages in a thread thinking they are all read
> (and actually marking all as read).

...that seems like a fatal bug in this script. Thanks for noting that
Sebastian.

I'm very interested in augmenting the test suite such that we could
write emacs-based tests that would capture this bug. It seems that with
the --batch, --load, and --funcall options it shouldn't be too hard to
write a modular function exercising emacs code and then execute it
no-interactively. Then we could either inspect the state of the database
to ensure the operation worked as desired, or else have the test
function write a buffer out to a file and test that the file has the
desired contents.

So that's something I'll be working on soon. And of course, I'll always
be glad to accept any help.

-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/20100224/bed6349a/attachment.pgp>


[notmuch] Introducing notmuchsync

2010-02-24 Thread Carl Worth
On Mon, 18 Jan 2010 16:12:28 +0100, "Sebastian Spaeth"  wrote:
> 
>  - Synchronizes the "S" flag with the "unread" tag (1-way). The
>  synchronization direction is decided by using either --sync (change
>  maildir flags according to notmuch) or --revsync (change notmuch tags
>  according to maildir). By default it always checks the mails from the
>  previous 30 days (but can also do --all mails if you have plenty of
>  RAM and time).
>  - Deletes all mail files that have the "delete" tag
>  - Quiet/normal/verbose logging 

Thanks for contributing this, Sebastian.

Let me know if you'd like to host this within the contrib directory of
the notmuch repository.

>  - It temporarily slurps in all your mails from the last 30 days into
>  RAM. I am waiting for "notmuchs show blah --output filename --output
>  tags" to improve that :). Generally the parsing of the output of
>  "notmuch show" is a bit hackyish with regexps at the moment.

OK. So we'll be adding an --output option to give you just filenames
soon, and we've got JSON output now so you can avoid hacky regexps now.

Elsewhere in the thread Jameson Rollins wrote:
> I should have mentioned in my previous mail that I think this tool is
> a great idea, and I plan on using it.  I just hope that all of it's
> functionality will be integrated directly into notmuch itself.

I think that's the open question still. How much of this kind of
functionality do we integrate into notmuch itself. I don't know the
answer to that question yet, but I'm quite happy to see people
experimenting with doing scripts like this on top of notmuch already.

I do know that I want to do thing to make such scripting easier,
(independent of whether the current functionality gets folded into
notmuch).

-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/20100224/6b59ed94/attachment.pgp>


[notmuch] [PATCH v3] notmuch.el: Refactor citation markup. Variables for minimum size, button text.

2010-02-24 Thread Carl Worth
On Sat, 16 Jan 2010 09:44:53 -0400, david at tethera.net wrote:
> This is the third rewrite of this patch. For some reason I squashed
> the series this time, but I still have the other branch if that would be 
> helpful.
> Essentially after using the patches for a while, I no longer thought that 
> people would like 
> one patch without the others.

Hmm...

Looks like I managed to merge in an earlier version of this, (but before
you added support for hiding top-posted messages). Do you have another
patch for that on top of master now?

(Or perhaps I'll find it already submitted as I work through the
backlog...)

As always, thanks for all your great work, David!

-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/20100224/ee143568/attachment.pgp>


[notmuch] JSON output as default [was: Re: [PATCH] Add an "--output=(json|text|)" command-line option...]

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 15:27:18 +0100 (CET), racin at free.fr wrote:
> > > I definitely want to be able to pipe single-field lists coming from
> > > notmuch to grep, xargs, shell for loops, etc. without having to
> > decode
> > > JSON.
> > 
> > While I would love to see JSON (even by default), I agree. If I just
> > want to code up a notmuch-based address book with sth like:
> > 
> > notmuch show to:Diana --output=to --sort=relevance --limit=20
> > 
> > just getting back a plain list of mail addresses is the easiest to
> > handle.
> 
> This would also be useful for the Emacs/Vim interfaces. For instance, my 
> smart completion patch
> would really benefit from notmuch being capable of outputing various fields 
> in all messages in plain text
> separated by newlines (this is even easier to handle in emacs code than 
> JSON). In fact, most of the C code I had
> to write for this patch is better replaced by the --output option...

Ok, I'm convinced.  I can see how they're both useful.  I had been
thinking more about the fact that text output isn't so useful for
multiline content (like message content), but I can see how it would be
useful for single line output.

I had also been thinking about the fact that the current "text" output,
specifically for the "show" command, *is* structured, but just not
according to any standard that I know of.  If the output is going to be
structured (ie. "show" output) then it should be in JSON format.  If
not, like the output of a single field that is a single line, then
having text output is definitely useful.

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/20100224/e4ba2422/attachment-0001.pgp>


[notmuch] [PATCH v2] notmuch-query.el: new file to support access to the notmuch database.

2010-02-24 Thread da...@tethera.net
From: David Bremner 

Initially this file provides one main function
notmuch-query-get-threads, which takes a set of search terms, and
returns a parsed set of matching threads as a lisp data structure.

A set of notmuch-query-map-* functions are provided to help map
functions over the data structure.

The function notmuch-query-get-message-ids uses this machinery to get
the set of message-ids matching a query.

This patch relies on the emacs directory  patch of
<1265773528-30794-1-git-send-email-david at tethera.net>
---

 This version is rebased against the json patches that eventually made
 it into master. Oddly, no actual changes were required based on
 Carl's change of "id" to "thread".   Some trailing whitespace was
 also removed.

 emacs/Makefile.local   |3 +-
 emacs/notmuch-query.el |   89 
 2 files changed, 91 insertions(+), 1 deletions(-)
 create mode 100644 emacs/notmuch-query.el

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index c6ca142..6c87a60 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -1,6 +1,7 @@
 dir=emacs
 emacs_sources= \
-   $(dir)/notmuch.el
+   $(dir)/notmuch.el  \
+   $(dir)/notmuch-query.el

 emacs_bytecode=$(subst .el,.elc,$(emacs_sources))

diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
new file mode 100644
index 000..86230ba
--- /dev/null
+++ b/emacs/notmuch-query.el
@@ -0,0 +1,89 @@
+; notmuch.el --- run notmuch within emacs
+;
+; Copyright ?? David Bremner
+;
+; This file is part of Notmuch.
+;
+; Notmuch is free software: you can redistribute it and/or modify it
+; under the terms of the GNU General Public License as published by
+; the Free Software Foundation, either version 3 of the License, or
+; (at your option) any later version.
+;
+; Notmuch is distributed in the hope that it will be useful, but
+; WITHOUT ANY WARRANTY; without even the implied warranty of
+; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+; General Public License for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with Notmuch.  If not, see .
+;
+; Authors: David Bremner 
+
+(require 'json)
+
+(defun notmuch-query-get-threads (search-terms  options)
+  "Return a list of threads of messages matching SEARCH-TERMS.
+
+A thread is a forest or list of trees. A tree is a two element
+list where the first element is a message, and the second element
+is a possibly empty forest of replies.
+"
+  (let  ((args (append '("show" "--format=json") search-terms))
+(json-object-type 'plist)
+(json-array-type 'list)
+(json-false 'nil))
+(with-temp-buffer
+  (progn
+   (apply 'call-process (append (list notmuch-command nil t nil) args))
+   (goto-char (point-min))
+   (json-read)
+
+;;
+;; Mapping functions across collections of messages.
+
+(defun notmuch-query-map-aux  (mapper function seq)
+  "private function to do the actual mapping and flattening"
+
+  (apply 'append
+(mapcar
+  (lambda (tree)
+(funcall mapper fn tree))
+  seq)))
+
+
+(defun notmuch-query-map-threads (fn threads)
+  "apply FN to every thread in  THREADS. Flatten results to a list.
+
+See the function notmuch-query-get-threads for more information."
+
+  (notmuch-query-map-aux 'notmuch-query-map-forest fn threads))
+
+
+(defun notmuch-query-map-forest (fn forest)
+  "apply function to every message in a forest. Flatten results to a list.
+
+See the function notmuch-query-get-threads for more information.
+"
+
+  (notmuch-query-map-aux 'notmuch-query-map-tree fn forest))
+
+
+(defun notmuch-query-map-tree (fn tree)
+  "Apply function FN to every message in TREE. Flatten results to a list
+
+See the function notmuch-query-get-threads for more information."
+
+  (cons (funcall fn (car tree)) (notmuch-query-map-forest fn (cadr tree
+
+
+;;
+;; Predefined queries
+
+(defun notmuch-query-get-message-ids ( search-terms)
+  "Return a list of message-ids of messages that match SEARCH-TERMS"
+
+  (notmuch-query-map-threads
+   (lambda (msg) (plist-get msg :id))
+   (notmuch-query-get-threads search-terms)))
+
+(provide 'notmuch-query)
-- 
1.6.5



[notmuch] [PATCH] Rework saving of attachments.

2010-02-24 Thread Keith Amidon
Resending to the list as well as just Carl...

{-- Tue, 23 Feb 2010 11:12:36 -0800: Carl  wrote: --}
  Carl> I apologize for the extraordinarly-late review, but here it
  Carl> is...

No problem at all.  You're updates on status have been sufficient to
convince me you were making progress and would get to everything
eventually and I've not exactly had any significant time to be playing
with notmuch  code anyway.  :-)

  Carl> I tried this patch out, wanted to like it, and almost pushed it
  Carl> out, but I decided against it in its current form. Here are some
  Carl> thoughts:

  Carl> 1. The commit message ("rework saving of attachments") is not
  Carl> adequate

Sure, I can make more granular commits.  Much of the work in this one
was inter-related in that my goal for the behavior couldn't be tested
until most of the work was done and I didn't take much care to commit
interim steps due to an over-eagerness to complete the changes. Easily
correctable.

  Carl> 2. A binding to save a single attachment (with only a prefix
  Carl> argument to select which) just isn't usable. 

Yes, I agree the current implementation for the save single attachment
is not the best.

  Carl> First, there's nothing in the UI to indicate the appropriate
  Carl> numbers to pass as the prefix argument, (other than manually
  Carl> counting the attachments). 

This is the real problem in my opinion.  My plan, which I've had no time
to implement, was to do something similar to what Gnus does; make a
button for each part and in the button text include the number of each
part.  This way the user would no longer have to manually count.

  Carl> And second, the functionality is simply too hidden and
  Carl> non-obvious. This is most dangerous because in the common case
  Carl> of a single attachment, the 'w' binding will seem to be saving
  Carl> all attachments setting up confusion if the user tries to save
  Carl> multiple attachments with this same keybinding.

  Carl>Now, having a function to save a single attachment is just
  Carl> fine, (leaving someone else to hook up a binding to a particular
  Carl> button, say). So I'd accept a patch that added that, but didn't
  Carl> add a direct key-binding for it.

I personally think that there should be a key-binding that allows saving
individual attachments and doesn't require navigating to a button in the
message and then doing something.  There are key-bindings in Gnus to do
this that I use all the time and I think notmuch should support
something similar.  Maybe the right approach is to combine both
functions on a single key-binding for example if no prefix argument is
given all attachments are saved and a prefix selects the specific
attachment.  

  Carl> 3. For saving multiple attachments, the feature I'd really like
  Carl> to see is the ability to specify a single directory and have all
  Carl> the attachments saved there.

I think the current code does support this functionality, although it
may not be completely obvious.  It adds a default directory in which to
save attachments (notmuch-default-save-dir).  When you type 'W' to save
all attachments it prompts for the location to save the first attachment
with a path built from the combination of notmuch-default-save-dir and
the filename or description of the attachment.  You can edit this path
to your heart's content.  Any subsequent attachments to be saved will
default to the directory into which you saved the most recent
attachment.

In use, if you want all attachments saved to the default directory with
their default filenames all you have to do is hit 'W' followed by one
carriage return per attachment.  If you want all of them saved to the
same directory but different from the default save directory you hit 'W'
edit the first path, then hit enter for each subsequent attachment.  The
changes support creating the destination directory path if it is not
already there.

  Carl> Obviously, this third feature is just something different than
  Carl> what the patch does, so not necessarily a reason to reject the
  Carl> patch. So what is it that the patch actually does again?

  Carl> I think the big advantage of the patch is getting rid of the
  Carl> initial prompting "save this attachment (foo)?". It occurs to me
  Carl> that a simpler way to get rid of that would be to simply not ask
  Carl> that question when the user hits 'w' and there *is* only a
  Carl> single attachment. Then, with multiple attachments, 'w' could
  Carl> prompt in turn as currently.

In my mind the key advantage of the patch was the much improved behavior
of the 'W' keybinding, described above.  Maybe that just wasn't obvious?

  Carl> That would leave open the ability to use 'W' for a command to
  Carl> write all attachments to a particular directory.

For this are you imagining that the user would first be prompted for the
directory in which to save the attachments and then all attachments
would be saved with some set of default names and no need 

[notmuch] [PATCH v2] notmuch-query.el: new file to support access to the notmuch database.

2010-02-24 Thread david
From: David Bremner brem...@unb.ca

Initially this file provides one main function
notmuch-query-get-threads, which takes a set of search terms, and
returns a parsed set of matching threads as a lisp data structure.

A set of notmuch-query-map-* functions are provided to help map
functions over the data structure.

The function notmuch-query-get-message-ids uses this machinery to get
the set of message-ids matching a query.

This patch relies on the emacs directory  patch of
1265773528-30794-1-git-send-email-da...@tethera.net
---

 This version is rebased against the json patches that eventually made
 it into master. Oddly, no actual changes were required based on
 Carl's change of id to thread.   Some trailing whitespace was
 also removed.

 emacs/Makefile.local   |3 +-
 emacs/notmuch-query.el |   89 
 2 files changed, 91 insertions(+), 1 deletions(-)
 create mode 100644 emacs/notmuch-query.el

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index c6ca142..6c87a60 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -1,6 +1,7 @@
 dir=emacs
 emacs_sources= \
-   $(dir)/notmuch.el
+   $(dir)/notmuch.el  \
+   $(dir)/notmuch-query.el
 
 emacs_bytecode=$(subst .el,.elc,$(emacs_sources))
 
diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
new file mode 100644
index 000..86230ba
--- /dev/null
+++ b/emacs/notmuch-query.el
@@ -0,0 +1,89 @@
+; notmuch.el --- run notmuch within emacs
+;
+; Copyright © David Bremner
+;
+; This file is part of Notmuch.
+;
+; Notmuch is free software: you can redistribute it and/or modify it
+; under the terms of the GNU General Public License as published by
+; the Free Software Foundation, either version 3 of the License, or
+; (at your option) any later version.
+;
+; Notmuch is distributed in the hope that it will be useful, but
+; WITHOUT ANY WARRANTY; without even the implied warranty of
+; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+; General Public License for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with Notmuch.  If not, see http://www.gnu.org/licenses/.
+;
+; Authors: David Bremner da...@tethera.net
+
+(require 'json)
+
+(defun notmuch-query-get-threads (search-terms rest options)
+  Return a list of threads of messages matching SEARCH-TERMS.
+
+A thread is a forest or list of trees. A tree is a two element
+list where the first element is a message, and the second element
+is a possibly empty forest of replies.
+
+  (let  ((args (append '(show --format=json) search-terms))
+(json-object-type 'plist)
+(json-array-type 'list)
+(json-false 'nil))
+(with-temp-buffer
+  (progn
+   (apply 'call-process (append (list notmuch-command nil t nil) args))
+   (goto-char (point-min))
+   (json-read)
+
+;;
+;; Mapping functions across collections of messages.
+
+(defun notmuch-query-map-aux  (mapper function seq)
+  private function to do the actual mapping and flattening
+
+  (apply 'append
+(mapcar
+  (lambda (tree)
+(funcall mapper fn tree))
+  seq)))
+
+
+(defun notmuch-query-map-threads (fn threads)
+  apply FN to every thread in  THREADS. Flatten results to a list.
+
+See the function notmuch-query-get-threads for more information.
+
+  (notmuch-query-map-aux 'notmuch-query-map-forest fn threads))
+
+
+(defun notmuch-query-map-forest (fn forest)
+  apply function to every message in a forest. Flatten results to a list.
+
+See the function notmuch-query-get-threads for more information.
+
+
+  (notmuch-query-map-aux 'notmuch-query-map-tree fn forest))
+
+
+(defun notmuch-query-map-tree (fn tree)
+  Apply function FN to every message in TREE. Flatten results to a list
+
+See the function notmuch-query-get-threads for more information.
+
+  (cons (funcall fn (car tree)) (notmuch-query-map-forest fn (cadr tree
+
+
+;;
+;; Predefined queries
+
+(defun notmuch-query-get-message-ids (rest search-terms)
+  Return a list of message-ids of messages that match SEARCH-TERMS
+
+  (notmuch-query-map-threads
+   (lambda (msg) (plist-get msg :id))
+   (notmuch-query-get-threads search-terms)))
+
+(provide 'notmuch-query)
-- 
1.6.5

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


Re: [notmuch] JSON output as default [was: Re: [PATCH] Add an --output=(json|text|) command-line option...]

2010-02-24 Thread Sebastian Spaeth
 I definitely want to be able to pipe single-field lists coming from
 notmuch to grep, xargs, shell for loops, etc. without having to decode
 JSON.

While I would love to see JSON (even by default), I agree. If I just
want to code up a notmuch-based address book with sth like:

notmuch show to:Diana --output=to --sort=relevance --limit=20

just getting back a plain list of mail addresses is the easiest to handle.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] JSON output as default [was: Re: [PATCH] Add an --output=(json|text|) command-line option...]

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 15:27:18 +0100 (CET), ra...@free.fr wrote:
   I definitely want to be able to pipe single-field lists coming from
   notmuch to grep, xargs, shell for loops, etc. without having to
  decode
   JSON.
  
  While I would love to see JSON (even by default), I agree. If I just
  want to code up a notmuch-based address book with sth like:
  
  notmuch show to:Diana --output=to --sort=relevance --limit=20
  
  just getting back a plain list of mail addresses is the easiest to
  handle.
 
 This would also be useful for the Emacs/Vim interfaces. For instance, my 
 smart completion patch
 would really benefit from notmuch being capable of outputing various fields 
 in all messages in plain text
 separated by newlines (this is even easier to handle in emacs code than 
 JSON). In fact, most of the C code I had
 to write for this patch is better replaced by the --output option...

Ok, I'm convinced.  I can see how they're both useful.  I had been
thinking more about the fact that text output isn't so useful for
multiline content (like message content), but I can see how it would be
useful for single line output.

I had also been thinking about the fact that the current text output,
specifically for the show command, *is* structured, but just not
according to any standard that I know of.  If the output is going to be
structured (ie. show output) then it should be in JSON format.  If
not, like the output of a single field that is a single line, then
having text output is definitely useful.

jamie.


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


Re: [notmuch] [PATCH] Rework saving of attachments.

2010-02-24 Thread Keith Amidon
Resending to the list as well as just Carl...

{-- Tue, 23 Feb 2010 11:12:36 -0800: Carl cwo...@cworth.org wrote: --}
  Carl I apologize for the extraordinarly-late review, but here it
  Carl is...

No problem at all.  You're updates on status have been sufficient to
convince me you were making progress and would get to everything
eventually and I've not exactly had any significant time to be playing
with notmuch  code anyway.  :-)

  Carl I tried this patch out, wanted to like it, and almost pushed it
  Carl out, but I decided against it in its current form. Here are some
  Carl thoughts:

  Carl 1. The commit message (rework saving of attachments) is not
  Carl adequate

Sure, I can make more granular commits.  Much of the work in this one
was inter-related in that my goal for the behavior couldn't be tested
until most of the work was done and I didn't take much care to commit
interim steps due to an over-eagerness to complete the changes. Easily
correctable.

  Carl 2. A binding to save a single attachment (with only a prefix
  Carl argument to select which) just isn't usable. 

Yes, I agree the current implementation for the save single attachment
is not the best.

  Carl First, there's nothing in the UI to indicate the appropriate
  Carl numbers to pass as the prefix argument, (other than manually
  Carl counting the attachments). 

This is the real problem in my opinion.  My plan, which I've had no time
to implement, was to do something similar to what Gnus does; make a
button for each part and in the button text include the number of each
part.  This way the user would no longer have to manually count.

  Carl And second, the functionality is simply too hidden and
  Carl non-obvious. This is most dangerous because in the common case
  Carl of a single attachment, the 'w' binding will seem to be saving
  Carl all attachments setting up confusion if the user tries to save
  Carl multiple attachments with this same keybinding.

  CarlNow, having a function to save a single attachment is just
  Carl fine, (leaving someone else to hook up a binding to a particular
  Carl button, say). So I'd accept a patch that added that, but didn't
  Carl add a direct key-binding for it.

I personally think that there should be a key-binding that allows saving
individual attachments and doesn't require navigating to a button in the
message and then doing something.  There are key-bindings in Gnus to do
this that I use all the time and I think notmuch should support
something similar.  Maybe the right approach is to combine both
functions on a single key-binding for example if no prefix argument is
given all attachments are saved and a prefix selects the specific
attachment.  

  Carl 3. For saving multiple attachments, the feature I'd really like
  Carl to see is the ability to specify a single directory and have all
  Carl the attachments saved there.

I think the current code does support this functionality, although it
may not be completely obvious.  It adds a default directory in which to
save attachments (notmuch-default-save-dir).  When you type 'W' to save
all attachments it prompts for the location to save the first attachment
with a path built from the combination of notmuch-default-save-dir and
the filename or description of the attachment.  You can edit this path
to your heart's content.  Any subsequent attachments to be saved will
default to the directory into which you saved the most recent
attachment.

In use, if you want all attachments saved to the default directory with
their default filenames all you have to do is hit 'W' followed by one
carriage return per attachment.  If you want all of them saved to the
same directory but different from the default save directory you hit 'W'
edit the first path, then hit enter for each subsequent attachment.  The
changes support creating the destination directory path if it is not
already there.

  Carl Obviously, this third feature is just something different than
  Carl what the patch does, so not necessarily a reason to reject the
  Carl patch. So what is it that the patch actually does again?

  Carl I think the big advantage of the patch is getting rid of the
  Carl initial prompting save this attachment (foo)?. It occurs to me
  Carl that a simpler way to get rid of that would be to simply not ask
  Carl that question when the user hits 'w' and there *is* only a
  Carl single attachment. Then, with multiple attachments, 'w' could
  Carl prompt in turn as currently.

In my mind the key advantage of the patch was the much improved behavior
of the 'W' keybinding, described above.  Maybe that just wasn't obvious?

  Carl That would leave open the ability to use 'W' for a command to
  Carl write all attachments to a particular directory.

For this are you imagining that the user would first be prompted for the
directory in which to save the attachments and then all attachments
would be saved with some set of default names and no need for further

Re: [notmuch] Introducing notmuchsync

2010-02-24 Thread Carl Worth
On Mon, 18 Jan 2010 16:12:28 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 
  - Synchronizes the S flag with the unread tag (1-way). The
  synchronization direction is decided by using either --sync (change
  maildir flags according to notmuch) or --revsync (change notmuch tags
  according to maildir). By default it always checks the mails from the
  previous 30 days (but can also do --all mails if you have plenty of
  RAM and time).
  - Deletes all mail files that have the delete tag
  - Quiet/normal/verbose logging 

Thanks for contributing this, Sebastian.

Let me know if you'd like to host this within the contrib directory of
the notmuch repository.

  - It temporarily slurps in all your mails from the last 30 days into
  RAM. I am waiting for notmuchs show blah --output filename --output
  tags to improve that :). Generally the parsing of the output of
  notmuch show is a bit hackyish with regexps at the moment.

OK. So we'll be adding an --output option to give you just filenames
soon, and we've got JSON output now so you can avoid hacky regexps now.

Elsewhere in the thread Jameson Rollins wrote:
 I should have mentioned in my previous mail that I think this tool is
 a great idea, and I plan on using it.  I just hope that all of it's
 functionality will be integrated directly into notmuch itself.

I think that's the open question still. How much of this kind of
functionality do we integrate into notmuch itself. I don't know the
answer to that question yet, but I'm quite happy to see people
experimenting with doing scripts like this on top of notmuch already.

I do know that I want to do thing to make such scripting easier,
(independent of whether the current functionality gets folded into
notmuch).

-Carl



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


Re: [notmuch] [PATCH] Simplify unread tag handling in emacs UI.

2010-02-24 Thread Carl Worth
On Wed, 17 Feb 2010 14:33:11 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On Tue, 19 Jan 2010 17:54:16 -0500, Jameson Rollins 
 jroll...@finestructure.net wrote:
  This patch is intended to greatly simplify the handling of the
  unread tag in the emacs UI.  This patch adds a new function
  'notmuch-show-mark-read', that removes the unread tag in
  notmuch-show-mode.  This function is then executed as a
  notmuch-show-hook, and by notmuch-show-next-message.  All of the
  functions that explicitly marked messages as unread are removed or
  renamed.

Hi Jameson,

Thanks for contributing the patch. This exact feature, (removing all
commands with and mark read in their names), has been on my todo list
for too long, and I'm anxious to remove it from that. But...

 It then checks the unread status in order to decide whether to proceed
 to the next again. So with your patch notmuch-show-next-unread-message
 will skip through all messages in a thread thinking they are all read
 (and actually marking all as read).

...that seems like a fatal bug in this script. Thanks for noting that
Sebastian.

I'm very interested in augmenting the test suite such that we could
write emacs-based tests that would capture this bug. It seems that with
the --batch, --load, and --funcall options it shouldn't be too hard to
write a modular function exercising emacs code and then execute it
no-interactively. Then we could either inspect the state of the database
to ensure the operation worked as desired, or else have the test
function write a buffer out to a file and test that the file has the
desired contents.

So that's something I'll be working on soon. And of course, I'll always
be glad to accept any help.

-Carl


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


[notmuch] [PATCH] notmuch.el: hide original message in top posted replies.

2010-02-24 Thread david
From: David Bremner brem...@unb.ca

This code treats top posted copies essentially like signatures, except
that it doesn't sanity check their length, since neither do their
senders.

In an unrelated cleanup, remove the let definition of sig-end, since
it was unused.

New user-visible variable:

  notmuch-show-original-button-format:   Allow customization of button text.
---

This is the unsquashed version of what was new in the v3 of the
citation patch, rebased against current master.

 notmuch.el |   40 
 1 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6482170..b1a590f 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -107,9 +107,15 @@
 The regexp can (and should) include $ to match the end of the
 line, but should not include ^ to match the beginning of the
 line. This is because notmuch may have inserted additional space
-for indentation at the beginning of the line. But notmuch will
-move past the indentation when testing this pattern, (so that the
-pattern can still test against the entire line).)
+for indentation at the beginning of the line.)
+
+(defvar notmuch-show-original-regexp \\(--+\s?[oO]riginal 
[mM]essage\s?--+\\)$
+  Pattern to match a line that separates original message from reply in 
top-posted message.
+
+The regexp can (and should) include $ to match the end of the
+line, but should not include ^ to match the beginning of the
+line. This is because notmuch may have inserted additional space
+for indentation at the beginning of the line.)
 
 (defvar notmuch-show-signature-button-format
   [ %d-line signature. Click/Enter to toggle visibility. ]
@@ -123,6 +129,13 @@ Can use up to one integer format parameter, i.e. %d)
 
 Can use up to one integer format parameter, i.e. %d)
 
+(defvar notmuch-show-original-button-format 
+  [ %d-line hidden original message. Click/Enter to show ]
+  String used to construct button text for hidden copies of messages
+
+Can use up to one integer format parameter, i.e. %d)
+
+
 (defvar notmuch-show-signature-lines-max 12
   Maximum length of signature that will be hidden by default.)
 
@@ -717,6 +730,9 @@ which this thread was originally shown.
   :supertype 'notmuch-button-invisibility-toggle-type)
 (define-button-type 'notmuch-button-signature-toggle-type 'help-echo mouse-1, 
RET: Show signature
   :supertype 'notmuch-button-invisibility-toggle-type)
+(define-button-type 'notmuch-button-original-toggle-type 'help-echo mouse-1, 
RET: Show original message
+  :supertype 'notmuch-button-invisibility-toggle-type)
+
 (define-button-type 'notmuch-button-headers-toggle-type 'help-echo mouse-1, 
RET: Show headers
   :supertype 'notmuch-button-invisibility-toggle-type)
 (define-button-type 'notmuch-button-body-toggle-type
@@ -768,9 +784,25 @@ is what to put on the button.
   (let ((citation-regexp (notmuch-show-citation-regexp depth))
(signature-regexp (concat (format ^[[:space:]]\\{%d\\} depth)
  notmuch-show-signature-regexp))
+   (original-regexp (concat (format ^[[:space:]]\\{%d\\} depth) 
+ notmuch-show-original-regexp))
+
(indent (concat \n (make-string depth ? 
 (goto-char beg)
 (beginning-of-line)
+
+(if (and ( (point) end) 
+(re-search-forward original-regexp end t))
+   (let* ((msg-start (match-beginning 0))
+  (msg-lines (1- (count-lines msg-start end
+ (notmuch-show-region-to-button 
+  msg-start
+  end
+  original
+  indent
+  (format notmuch-show-original-button-format msg-lines)
+  )))
+
 (while (and ( (point) end)
(re-search-forward citation-regexp end t))
   (let* ((cite-start (match-beginning 0))
@@ -786,10 +818,10 @@ is what to put on the button.
   (format notmuch-show-citation-button-format
   (- cite-lines notmuch-show-citation-lines-prefix))
   
+
 (if (and ( (point) end)
 (re-search-forward signature-regexp end t))
(let* ((sig-start (match-beginning 0))
-  (sig-end (match-end 0))
   (sig-lines (1- (count-lines sig-start end
  (if (= sig-lines notmuch-show-signature-lines-max)
  (notmuch-show-region-to-button
-- 
1.6.6

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


Re: [notmuch] [PATCH] Support for deletion (patch included)

2010-02-24 Thread Carl Worth
On Sun, 13 Dec 2009 12:54:09 +0100, Matthieu Lemerre ra...@free.fr wrote:
 I forgot the attachment..

Hi Matthieu,

This is a very interesting patch. Thanks for contributing it.

Could you also write a commit message describing what the patch does?
The easiest way for me to apply that would be if you would create a git
commit, then run git format-patch origin/master and mail the resulting
files, (the git send-email command can be used here, or you can insert
the files into a mail-composition buffer and modify them as needed).

A couple of minor comments on the patch:

  (define-key map a 'notmuch-search-archive-thread)
 +(define-key map d 'notmuch-search-mark-as-deleted)

For consistency, let's name this notmuch-search-delete-thread.

And we'll probably want a notmuch-show-delete-message function as well,
no?

 +(defvar notmuch-search-history nil)

Excellent! I've wanted custom search history for a while, and just
didn't know how to do it with (interactive s). It looks easy enough
with read-string as you're doing here. But this is independent
functionality, so would be preferred as an independent patch/commit.

(forward-line))
  
 +
 +(defun notmuch-search-mark-as-deleted ()
 +  Mark the currently selected thread as deleted (set its \deleted\ tag).
 +This function advances the next thread when finished.
 +  (interactive)
 +  (notmuch-search-add-tag deleted)
 +  (forward-line))
 +
 +
  (defun notmuch-search-process-sentinel (proc msg)

Watch that extra whitespace. The convention is a single line of
whitespace between each function.

And should we also archive the thread before removing the deleted tag?

 +With prefix argument, include deleted items.

That's a pretty good interface I think.

Another approach would be to do something like what sup does---that
would be to scan the search terms and if it contains tag:deleted and
all then don't prepend the not tag:deleted and to the search
string. The assumption there is that if the user is explicitly
mentioning the deleted tag, then we should just rely on the user to
explicitly describe how the tag should be treated.

That's perhaps not an unreasonable heuristic, and might be done even in
addition to the prefix-argument approach. But that could be an
additional commit, and I won't require it.

 +  (interactive (let* ((prefix current-prefix-arg)
 +   (query (if prefix
 +  (read-string Notmuch search (including 
 deleted): 
 +   notmuch-search-query-string
 +   'notmuch-search-history)
 +(read-string Notmuch search:  nil
 + 'notmuch-search-history

Why is the second (initial-input) argument non-nil in one case, but nil
in the other? The documentation for `read-string' says the argument is
deprecated and should be nil in all new code.

 +  (list query nil prefix)))
 +  (let ((real-query (if include-deleted query 
 +   (concat not tag:deleted and ( query 
 + (buffer (get-buffer-create (concat *notmuch-search- query
 *

Does the include-deleted case actually work? I don't see anything in the
code that sets this variable. (I'm just reviewing here--I haven't tested
it manually).

 @@ -1351,7 +1374,6 @@ search.
  
  Runs a new search matching only messages that match both the
  current search results AND the additional query string provided.
 -  (interactive sFilter search: )
(let ((grouped-query (if (string-match-p notmuch-search-disjunctive-regexp 
 query) (concat (  query  )) query)))
  (notmuch-search (concat notmuch-search-query-string  and  
 grouped-query) notmuch-search-oldest-first)))

Is this just an accidental chunk in the patch? I don't see why this
function should become non-interactive now.

Thanks again,

-Carl


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


Re: [notmuch] Introducing notmuchsync

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth cwo...@cworth.org wrote:
 Elsewhere in the thread Jameson Rollins wrote:
  I should have mentioned in my previous mail that I think this tool is
  a great idea, and I plan on using it.  I just hope that all of it's
  functionality will be integrated directly into notmuch itself.
 
 I think that's the open question still. How much of this kind of
 functionality do we integrate into notmuch itself. I don't know the
 answer to that question yet, but I'm quite happy to see people
 experimenting with doing scripts like this on top of notmuch already.
 
 I do know that I want to do thing to make such scripting easier,
 (independent of whether the current functionality gets folded into
 notmuch).

Hey, Carl.  Yeah, this was an old post and there's been lots of
discussion about it.  I'm certainly more flexible about my position now
than I think I was originally.

In fact, I actually gave up on syncing notmuch and maildir, and am
basically punting on maildir altogether.  This is slightly problematic
because notmuch is still missing some key features so I occasionally
have to use other mailers to achieve certain things (especially OpenPGP
stuff).  I worry about it down the line as well, if I ever have to use
another mailer for any reason.  All mail I've received since my switch
to notmuch will show up as unread in maildir readers.

I think notmuch wrapper scripts like notmuchsync are going to be crucial
for notmuch down the line, so I definitely agree that doing everything
possible to make it easier for them is a very good thing.  I am using
notmuchsync for deleting delete tagged messages, for which it's very
useful.  It's pretty slow, though, which I've been chalking up to the
fact that it has to parse the notmuch show output.  Once notmuch can
output just the paths to messages matching search results that should
get much much faster.

jamie.


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


Re: [notmuch] Git feature branch

2010-02-24 Thread Carl Worth
On Wed, 27 Jan 2010 14:17:39 -0500, Ben Gamari bgam...@gmail.com wrote:
 I agree. There is no good reason to switch away from the existing
 infrastructure. If he wants, Carl can give regular contributors their
 own repositories on notmuchmail.org if some people have difficulties
 providing it themselves. After all, this is one of the strengths of
 distributed version control.

I should emphasize that point:

I think it's great that people are posting their own notmuch
repositories wherever they see fit. Please continue doing that.

Also, if anybody would like to host such a repository on the
notmuchmail.org server, I'm more than happy to arrange that. Just let me
know.

-Carl


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


Re: [notmuch] [PATCH] add notmuch-show-delete keybinding 'd'

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 10:53:50 -0800, Carl Worth cwo...@cworth.org wrote:
 But this patch does have two good ideas not in the other patch, (both of
 which I mentioned in the review):
 
 1. It adds a keybinding to the notmuch-show mode
 
 2. It removes the inbox and unread tags while adding the tag to
indicate deletion.

Hey, Carl.  Why is this last point important?  I've been using my own
patchs for handling deleted messages, and all deleting a message or
thread does is add the delete tag.  Why should it modify any other
tags?  A message/thread should be allowed to be both deleted and in the
inbox.

As for unread, I think that should be handled by actually reading the
message, not by manually applying a state to it.

FWIW, below are the functions I've added to my notmuch .el to handle
message/thread deleting.

jamie.

(defun notmuch-search-delete-thread ()
  Delete thread (add \delete\ tag).

This function advances the next thread when finished.
  (interactive)
  (notmuch-search-add-tag delete)
  (forward-line))

(define-key notmuch-search-mode-map d 'notmuch-search-delete-thread)

(defun notmuch-show-delete-message ()
  Delete message (add \delete\ tag).

Add the \delete\ tag to message. Then kill this buffer and
show the next thread from the search from which this thread was
originally shown.
  (interactive)
  (notmuch-show-add-tag delete)
  (let ((parent-buffer notmuch-show-parent-buffer))
(kill-this-buffer)
(if parent-buffer
(progn
  (switch-to-buffer parent-buffer)
  (forward-line)

(define-key notmuch-show-mode-map d 'notmuch-show-delete-message)


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


Re: [notmuch] Git feature branch

2010-02-24 Thread Carl Worth
On Wed, 03 Feb 2010 22:58:05 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 Once the project becomes more mature and other developers are
 vetting patches, then their branches can take over as master in the
 absence of an outdated canonical master.

The other thing that will happen as the project matures is that I expect
to start merging other people's carefully vetted and reviewed
branches. This will happen as people start to take ownership of
particular code areas and we establish mutual trust on taste, code
review, testing, etc.

I think that will be the real solution for future bottlenecks when I'm
not available for much patch review due to travel, sickness,
hectic-life-in-general, etc.

-Carl


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


Re: [notmuch] [PATCH] Simplify unread tag handling in emacs UI.

2010-02-24 Thread Jameson Rollins
On Wed, 24 Feb 2010 10:26:47 -0800, Carl Worth cwo...@cworth.org wrote:
 On Wed, 17 Feb 2010 14:33:11 +0100, Sebastian Spaeth sebast...@sspaeth.de 
 wrote:
  On Tue, 19 Jan 2010 17:54:16 -0500, Jameson Rollins 
  jroll...@finestructure.net wrote:
   This patch is intended to greatly simplify the handling of the
   unread tag in the emacs UI.  This patch adds a new function
   'notmuch-show-mark-read', that removes the unread tag in
   notmuch-show-mode.  This function is then executed as a
   notmuch-show-hook, and by notmuch-show-next-message.  All of the
   functions that explicitly marked messages as unread are removed or
   renamed.

 Thanks for contributing the patch. This exact feature, (removing all
 commands with and mark read in their names), has been on my todo list
 for too long, and I'm anxious to remove it from that. But...

  It then checks the unread status in order to decide whether to proceed
  to the next again. So with your patch notmuch-show-next-unread-message
  will skip through all messages in a thread thinking they are all read
  (and actually marking all as read).
 
 ...that seems like a fatal bug in this script. Thanks for noting that
 Sebastian.

I certainly don't see it as fatal, but it is something we should
resolve.  I think the simplification that the patch provides is worth
it.

I'm seeing the notmuch-show-next-unread-message as a non-interactive
function that's not currently called by any other functions, and is
therefore not being used.  Sebastian, are you using that in a private
function, or am I misreading the code?

jamie.


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


Re: [notmuch] [PATCH] Calls to notmuch get queued and executed asynchronously.

2010-02-24 Thread James Vasile
Sleep between retrying asynchronous notmuch commands and check for
notmuch-process before firing off a new one

If the db is locked when notmuch tries to write to it, an error is
reported to the client (in this case, notmuch.el).  Instead of
accepting that error, wait a small amount of time and then try again.

Also, don't start multiple asynchronous processes.
---
 notmuch.el |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 7fc63e9..31e89b9 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1402,9 +1402,14 @@ args is a list of arguments to notmuch.  ex: (\tag\ 
\+list\
 
 Calls to notmuch are queued and called asynchronously.
   (setq notmuch-asynch-queue (append notmuch-asynch-queue (list args)))
-  (when (= (length notmuch-asynch-queue) 1)
+  (when (and (= (length notmuch-asynch-queue) 1)
+(not (get-process notmuch-process)))
 (apply 'notmuch-call-notmuch-process-asynch (pop notmuch-asynch-queue
-  
+
+(defun notmuch-asynch-sleep-sentinel (process event)
+  After we sleep, try a command from the notmuch queue
+  (apply 'notmuch-call-notmuch-process-asynch (pop notmuch-asynch-queue)))
+
 (defun notmuch-call-notmuch-process-asynch-sentinel (process event)
   Handle the exit of a notmuch asynch process.
 
@@ -1416,11 +1421,16 @@ command, try it again.
 (if (= (process-exit-status process) 0)
(kill-buffer (buffer-name (process-buffer process)))
(if (search-forward Unable to acquire database write lock nil t)
-   (apply 'notmuch-call-notmuch-process-asynch (cdr (process-command 
process)))
+   (progn
+ (push (cdr (process-command process)) notmuch-asynch-queue)
+ (set-process-sentinel 
+  (start-process notmuch-sleep nil sleep 3)
+  'notmuch-asynch-sleep-sentinel))
(error (format %s: %s (join-string-list (process-command process))
   (buffer-string))
   (apply 'notmuch-call-notmuch-process-asynch (pop notmuch-asynch-queue)))
 
+
 (defun notmuch-call-notmuch-process (rest args)
   Synchronously invoke \notmuch\ with the given list of arguments.
 
-- 
1.6.3.3

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


Re: [notmuch] [PATCH] add notmuch-show-delete keybinding 'd'

2010-02-24 Thread Carl Worth
On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
  2. It removes the inbox and unread tags while adding the tag to
 indicate deletion.
 
 Hey, Carl.  Why is this last point important?

I guess I was imagining the case of running notmuch search tag:inbox
at the command-line. That output will get out of hand fairly quickly if
it includes all deleted messages back to the beginning of time, (or as
far back as the window of actually deleting files from the
mailstore[*]).

But you're right that tags should really be handled orthogonally. Maybe
what we want is lower-level support for the deleted tag? Other than
just the high-level emacs interface?

That could put *more* direct interpretation of specific tags in the low
levels. And this is the opposite direction of where we've been going (or
talking about at least). We've currently got inbox and unread inside
the low levels and there's been talking or removing those, switching to
just new or making it all configurable.

I do know that I also want to have low-level support for muted (aka
killed threads). For that I want an --exclude option to notmuch search
that would look something like this:

notmuch search --exclude=negative-search-terms positive-search-terms

Where the result would be the set difference of the threads matched by
the two sets of search terms. Perhaps with something like that in place
all we'd want in addition would be a configuration option to add
--exclude=tag:muted by default. And if we go that route, perhaps we
could have an option for an implicit and not tag:deleted for the
search terms as well.

I do worry about making the command-line tool hard to use without a
configuration file, but it also seems very appealing to keep the lowest
levels very general to allow people to experiment with whatever they
want on top.

-Carl

[*] My eventual plan for detected spam and manually deleted messages is
to keep them in the mail store so they are searchable for some time (a
month or two) and then deleting them after that (with something like a
cron job using a convenient --before=2 months ago syntax to a notmuch
search command).


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


[notmuch] envelope-to

2010-02-24 Thread James Vasile
Can notmuch search for envelope-to:?  Or for that matter, can it
search for arbitrary headers?

I get a lot of BCC mail.  The envelope-to is a good way for me to know
which of my various addresses was BCC'd.

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


Re: [notmuch] patchwork test instance

2010-02-24 Thread martin f krafft
also sprach Carl Worth cwo...@cworth.org [2010.02.24.2010 +0100]:
  Carl, would you consider bouncing messages to addresses like
  patchwork+rejec...@patchwork.notmuchmail.org? That would make it
  trivial for me to write glue to update patchwork automatically.
 
 Now you're talking my language, Martin!
 
 I'm disinclined to go to a web browser, find the right buttons and
 push them, but it's easy for me to add an extra address when
 declining a patch, (since I have to write that email message
 already and I can even just add a keybinding to add the extra
 address).

This is trivial to implement, but I don't see myself able to do that
anytime soon. The basic idea is the same as the Git hook[0], and if
someone wanted to take a shot, I'd be happy to create an account on
the machine hosting the patchwork instance.

0. http://lists.ozlabs.org/pipermail/patchwork/2010-February/000224.html

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
most people become bankrupt through having invested too heavily in
 the prose of life. to have ruined one's self over poetry is an
 honour.
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [PATCH] Support for deletion (patch included)

2010-02-24 Thread racin
Hi Carl,

 Could you also write a commit message describing what the patch does?
 The easiest way for me to apply that would be if you would create a git
 commit, then run git format-patch origin/master and mail the resulting
 files, (the git send-email command can be used here, or you can insert
 the files into a mail-composition buffer and modify them as needed).
 

OK, here it is (comments below). I had trouble splitting the patches into a 
patch series; I
found git add -p, but isn't there a better interface for selecting patches?

From bdee9558d93bffb97c80632f522288e059deb7c2 Mon Sep 17 00:00:00 2001
From: Matthieu Lemerre ra...@racin.rez-gif.supelec.fr
Date: Thu, 25 Feb 2010 00:24:24 +0100
Subject: [PATCH 1/2] Add and use notmuch-show-forall-in-thread macro

---
 notmuch.el |   17 +++--
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6482170..5d7342a 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -321,17 +321,22 @@ pseudoheader summary
 (cons (notmuch-show-get-message-id) nil)))
  (notmuch-show-set-tags (sort (set-difference tags toremove :test 
'string=) 'string))
 
-(defun notmuch-show-archive-thread-maybe-mark-read (markread)
-  (save-excursion
+(defmacro notmuch-show-forall-in-thread (rest body)
+  Executes BODY with point in all messages of the current thread.
+  `(save-excursion
 (goto-char (point-min))
 (while (not (eobp))
-  (if markread
- (notmuch-show-remove-tag unread inbox)
-   (notmuch-show-remove-tag inbox))
+  ,@body
   (if (not (eobp))
  (forward-char))
   (if (not (re-search-forward notmuch-show-message-begin-regexp nil t))
- (goto-char (point-max)
+ (goto-char (point-max))
+
+(defun notmuch-show-archive-thread-maybe-mark-read (markread)
+  (notmuch-show-forall-in-thread
+  (if markread
+ (notmuch-show-remove-tag unread inbox)
+   (notmuch-show-remove-tag inbox)))
   (let ((parent-buffer notmuch-show-parent-buffer))
 (kill-this-buffer)
 (if parent-buffer
-- 
1.6.5


This first patch is helpful for factorizing out code. Basically, it allows to
apply a message-only command to all the thread.

From 0073152e3fa7dd11d88de28e87eec7762cdbbbeb Mon Sep 17 00:00:00 2001
From: Matthieu Lemerre ra...@racin.rez-gif.supelec.fr
Date: Thu, 25 Feb 2010 00:25:51 +0100
Subject: [PATCH 2/2] Add support for deletion in the emacs interface

---
 notmuch.el |   56 +---
 1 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 5d7342a..0285573 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -92,6 +92,8 @@
 (define-key map x 'notmuch-show-archive-thread-then-exit)
 (define-key map A 'notmuch-show-mark-read-then-archive-thread)
 (define-key map a 'notmuch-show-archive-thread)
+(define-key map d 'notmuch-show-delete-thread)
+(define-key map D 'notmuch-show-delete-message)
 (define-key map p 'notmuch-show-previous-message)
 (define-key map N 'notmuch-show-mark-read-then-next-open-message)
 (define-key map n 'notmuch-show-next-message)
@@ -380,6 +382,23 @@ buffer.
   (notmuch-show-archive-thread)
   (kill-this-buffer))
 
+(defun notmuch-show-delete-message ()
+  Delete current message (sets its deleted tag).
+  (interactive)
+  (notmuch-show-add-tag deleted))
+
+(defun notmuch-show-delete-thread()
+  Delete each message in thread.
+  (interactive)
+  (notmuch-show-forall-in-thread
+   (notmuch-show-delete-message)))
+
+(defun notmuch-show-delete-thread-and-exit()
+  Delete each message in thread, then exit back to search results.
+  (interactive)
+  (notmuch-show-delete-thread)
+  (kill-this-buffer))
+
 (defun notmuch-show-mark-read-then-archive-then-exit ()
   Remove unread tags from thread, then archive and exit to search results.
   (interactive)
@@ -1227,6 +1246,7 @@ matching this search term are shown if non-nil. 
 (define-key map [mouse-1] 'notmuch-search-show-thread)
 (define-key map * 'notmuch-search-operate-all)
 (define-key map a 'notmuch-search-archive-thread)
+(define-key map d 'notmuch-search-delete-thread)
 (define-key map - 'notmuch-search-remove-tag)
 (define-key map + 'notmuch-search-add-tag)
 (define-key map (kbd RET) 'notmuch-search-show-thread)
@@ -1235,6 +1255,7 @@ matching this search term are shown if non-nil. 
 (fset 'notmuch-search-mode-map notmuch-search-mode-map)
 
 (defvar notmuch-search-query-string)
+(defvar notmuch-search-history nil)
 (defvar notmuch-search-oldest-first t
   Show the oldest mail first in the search-mode)
 
@@ -1446,6 +1467,13 @@ This function advances the next thread when finished.
   (notmuch-search-remove-tag inbox)
   (forward-line))
 
+(defun notmuch-search-delete-thread ()
+  Mark the currently selected thread as deleted (set its \deleted\ tag).
+This function advances the next thread when finished.
+  (interactive)
+