[notmuch] Initial tagging

[James Vasile]

On Thu, 25 Feb 2010 17:02:08 -0800, Carl Worth  wrote:
> One distinction is that I have all of my "notmuch tag" commands operate
> globally rather than just on new messages. One of the things that really
> annoyed be about sup was that the support for automatic tagging worked
> as a hook on messages as they were processed. So I couldn't use any of
> the tags for searches prior to the time that I had added a particular
> tag rule. I definitely didn't want to replicate that bug.

Sometimes I manually override a rule-based tag.  If automatic tagging
operated on old messages, overrides could be superseded.  When I add
automatic tag rules, I first execute them manually and globally from the
command line.

> To do my "global" searches quickly, I do a similar subsetting, but it's
> much simpler. If I'm adding the "notmuch" tag I do "and not
> tag:notmuch". We've even had the proposal of making "notmuch tag" do
> that automatically.

That sounds like a good idea.  What happened with that proposal?

> Meanwhile, I'm planning on eventually moving entirely away from any tags
> that are driven entirely by searches like this. Instead, I'd like to
> just have good support for "saved searches" where we have some syntax to
> perform string expansion on configured search terms. 

Saved searches is a very good idea.  I look forward to it.

[notmuch] vim client

[Ben Gamari]

Excerpts from Arian Kuschki's message of Thu Feb 25 12:03:30 -0500 2010:
> On Sat 20, 12:34 -0500, Ben Gamari wrote:
> 
> > The real problem is all notmuch calls are synchronous. Vim unfortunately
> > lacks the excellent asynchronous subprocess interface that emacs has.
> > Therefore, I'm afraid the vim client is going to be just as unuable
> > until someone has implemented asynchronous subprocess support.
> 
> What is the problem that you are trying to solve with asynchronous 
> sub process support that you cannot solve with things like 
> ':!notmuch tag +sometag pattern &' or with using temp files and 
> ":autoread" for views that need to be updated regularly?
> This is a genuine question, I am just not very knowledgeable about these 
> technicalities.

The client currently processes search results so it can display only the
desired fields in the results buffer. This would make the autoread
option quite expensive. On the other hand, if you can think of a way to
avoid preprocessing results, we could probably make it work. That being
said, I think the correct solution is to simply give vim a more powerful
subprocess system. I think this represents an important shortcoming
of vim's current scripting environment.

> 
> Do you think improved sub process support will ever be merged into 
> mainline vim seeing that is somewhat against the vim philosophy (or 
> isn't it?)?
> 
What do you mean by the vim philosophy? It wouldn't incorporate much
additional complexity and you gain quite a bit of flexibility when you
can decouple the subprocess life-cycle from the script's flow of
execution. This was actually discussed[1] not so long ago on the vim list
and a few people of unknown import seemed to support the idea of having
more powerful subprocess infrastructure. I think it's pretty much just a
matter of finding someone with some time to spare.

> > and I would
> > far prefer to use notmuch from within vim than from another specialized
> > application.
> 
> I agree. I talked to Bart, the creator of the vim client and he said he 
> was planning to resume his work on it in April at the earliest. I would 
> really like to see a usable client before that, and I don't think there 
> is that much to do to make that happen really. There is lots of existing 
> code we can use for things like json parsing and handling MIME stuff in 
> the python standard libraries for example. If anybody wants to fork Bart's 
> repo I would 
> be happy to submit patches and test , but I lack the qualification to 
> maintain a fork myself unfortunately.

I agree that a notmuch frontend implemented in Python would be nice (although 
that
might just be the result of my having effectively zero experience
scripting with vim's native language).

- Ben


[1] http://article.gmane.org/gmane.editors.vim.devel/25108

[notmuch] vim client

[Arian Kuschki]

On Sat 20, 12:34 -0500, Ben Gamari wrote:

> The real problem is all notmuch calls are synchronous. Vim unfortunately
> lacks the excellent asynchronous subprocess interface that emacs has.
> Therefore, I'm afraid the vim client is going to be just as unuable
> until someone has implemented asynchronous subprocess support.

What is the problem that you are trying to solve with asynchronous 
sub process support that you cannot solve with things like 
':!notmuch tag +sometag pattern &' or with using temp files and 
":autoread" for views that need to be updated regularly?
This is a genuine question, I am just not very knowledgeable about these 
technicalities.

Do you think improved sub process support will ever be merged into 
mainline vim seeing that is somewhat against the vim philosophy (or 
isn't it?)?

> and I would
> far prefer to use notmuch from within vim than from another specialized
> application.

I agree. I talked to Bart, the creator of the vim client and he said he 
was planning to resume his work on it in April at the earliest. I would 
really like to see a usable client before that, and I don't think there 
is that much to do to make that happen really. There is lots of existing 
code we can use for things like json parsing and handling MIME stuff in 
the python standard libraries for example. If anybody wants to fork Bart's repo 
I would 
be happy to submit patches and test , but I lack the qualification to 
maintain a fork myself unfortunately.

[notmuch] Initial tagging

[Carl Worth]

eego.com )' and not tag:meego

# Finally, a few subject-based tags
notmuch tag +intel subject:xf86-video-intel and not tag:intel
notmuch tag +sup subject:sup-talk and not tag:sup
notmuch tag +pdx subject:pdx and not tag:pdx

# And some sender-based tags
notmuch tag +family from:theworths.org and not tag:family'

# Keep most Debian bug traffic out of my inbox
notmuch tag +debbugs '(' to:bugs.debian.org or from:bugs.debian.org ')' and not 
tag:debbugs
notmuch tag -inbox tag:inbox and tag:debbugs and not '(' '"Package: cairo"' or 
'"Package: notmuch"' ')'

echo "Done."

# a snippet of .emacs #
(setq notmuch-folders '(("inbox" . "tag:inbox")
("tome" . "tag:inbox and (tag:to-me or tag:family)")
("tome-select" . "tag:inbox and (tag:to-me or 
tag:family) and not tag:notmuch and not tag:cairo")
("other" . "tag:inbox AND not (tag:to-me or 
tag:announce or tag:notmuch or tag:intel or tag:bugs or tag:cairo or 
tag:xorgboard or tag:xorg or tag:debian or tag:sup or tag:lca or tag:meego or 
tag:nickle or tag:pdx)")
("announce" . "tag:inbox AND tag:announce")
("notmuch" . "tag:inbox AND tag:notmuch")
("intel" . "tag:inbox AND tag:intel")
("bugs" . "tag:inbox AND tag:bugs")
("cairo" . "tag:inbox AND tag:cairo")
("xorgboard" . "tag:inbox AND tag:xorg-board")
("xorg" . "tag:inbox AND tag:xorg")
("debian" . "tag:inbox AND tag:debian")
("sup" . "tag:inbox AND tag:sup")
("lca" . "tag:inbox AND tag:lca")
("meego" . "tag:inbox AND tag:meego")
("nickle" . "tag:inbox AND tag:nickle")
("pdx" . "tag:inbox AND tag:pdx")
("todo" . "tag:todo and not tag:cairo and not 
tag:notmuch and not tag:intel")
("inteltodo" . "(tag:todo and tag:intel) or 
tag:todo-intel")
("notmuchtodo" . "(tag:todo and tag:notmuch) or 
tag:todo-notmuch")
("cairotodo" . "(tag:todo and tag:cairo) or 
tag:todo-cairo")
))
-- 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/20100225/c9ddffa6/attachment.pgp>

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

[ra...@free.fr]

Carl: The patch in the mail has problems; apparently I have to manually add 
scissorlines to the mail for it
to be processed by git-am. I thought this was automatically added. (I hate the 
git UI -- nothing is consistent,
concepts have different names, the definition of scissor lines is as precise as 
"A line that mainly consists of scissors (either ">8" or "8<") and perforation 
(dash "-") --, but I guess we can get used to it after a while...)

I'll send you a proper patch as soon as I can. Meanwhile, I'm sure you have 
comments on this updated patch!

Matthieu

?: "Carl Worth" 
Cc: notmuch at notmuchmail.org
Envoy?: Jeudi 25 F?vrier 2010 00h00:04 GMT +00:00 GMT - Grande-Bretagne, 
Irlande, Portugal
Objet: Re: [notmuch] [PATCH] Support for deletion (patch included)

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 
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 ( 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"))
+  , at 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 
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)
+

[notmuch] Initial tagging

[James Vasile]

I'm slowly groping my way to using the notmuch emacs client as my
routine MUA.  As I coerce it into tagging and displaying the way I want,
the next big question was automatically tagging things and getting them
in to notmuch.

I'm curious as to what people are doing in this regard.

My solution involves cron running a sync_email script.  Sync_email does
the correct dance to make sure it only ever runs one instance at a time.
It also logs to syslog.  The script runs offlineimap, a mail_filter
script that sorts mail in maildirs (for wanderlust, the MUA I'm hoping
to leave behind), and then finally a shell script to do notmuch new and
initial tagging.

The tagging script uses the inbox tag to identify new mail, tags it
according to criteria, then removes the inbox tag from anything it found
a match for.  Uncategorized mail keeps the inbox tag so I can inspect it
later and make rules for it (or tag it manually).

Also, prepending "tag:inbox and" to search criteria restricts the
tagging to a small subset of the db, which makes the tagging script run
fairly quickly.  My unexpurgated tagging script has almost 100 rules for
tagging, and I expect it to grow over time.

## notmuch-tag.sh 
#!/bin/bash

bin=/usr/local/bin/notmuch

function notmuch {
echo $1
while [ 1 -gt 0 ]; do
result=`$bin $1 2>&1` 
regex="already locked"

if [[ $result =~ $regex ]]; then
echo "Xapian DB busy.  Retrying in 2 seconds"
else
if [ -n "$result" ]; then
echo $result
fi
return
fi

sleep 2
done
}

function tag_new { notmuch "tag $1 tag:inbox and ($2)"; }
function blacklist { tag_new "-inbox -unread +delete" $1; }

notmuch new

blacklist "from:xxx at example.com or from yyy at example.com"

# voicemail
tag_new "-inbox +voicemail"  "from:ast at example.com"

# friends
tag_new "+friend +mathieu" "mathieu or ejm2106 or emily at example.com"
tag_new "+friend +balktick" "balktick"

# open community services
tag_new "+ocs" "open community services or opencommunityservices"

# okos
tag_new "+okos" "jim and glaser and not LinkedIn"
tag_new "+okos" "joshlevy.ny at example.com"
tag_new "+okos" "enright at example.com"

# book liberator
tag_new "+bklib" "wnf at example.com or bkrpr"

# joomla
tag_new "+osm" "from:waring or to:waring"
tag_new "+osm" "from:dave.huelsmann at example.com or to:dave.huelsmann at 
example.com"
tag_new "+osm" "james.vasile at example.com"
tag_new "+osm" "joomla"

#lists
tag_new "+list +notmuch" "to:notmuchmail.org or notmuch"
tag_new "+list +stumpwm" "to:stumpwm-devel at nongnu.org or stumpwm"
tag_new "+list +bklib" "to:bklib at googlegroups.com"

## Catchalls for sflc, hv, etc.
tag_new "+sflc" "not tag:list and not tag:friend and softwarefreedom.org and 
not tag:osm"
tag_new "+sflc" "to:firm at example.com"
tag_new "+hv" "hackervisions.org and not tag:list and not tag:friend"
tag_new "+gmail" "(to:jvasile at example.com or from:jvasile at example.com) 
and not tag:list and not tag:friend"

## Mark mine unread
tag_new "-unread" "from:james at example.com"
tag_new "-unread" "from:vasile at example.com"
tag_new "-unread" "from:james.vasile at example.com"

## Remove inbox tag
tag_new "-inbox" "tag:sflc or tag:hv or tag:list or tag:osm or tag:okos or 
tag:friend or tag:bklib"


# sync_email #
#!/bin/sh

## Sync email unless we're already in the process of syncing.

SCRIPTNAME=`basename $0`
PIDDIR=/home/vasile/var/run/${SCRIPTNAME}
PIDFILE=${PIDDIR}/${SCRIPTNAME}.pid

## Do the double-lock with a dir and a pid file
if ! mkdir ${PIDDIR} 2>/dev/null; then

   sleep 3 # give the other process time to write its pid

   if [ -f ${PIDFILE} ]; then
  #verify if the process is actually still running under this pid
  OLDPID=`cat ${PIDFILE}`
  RESULT=`ps -ef | grep ${OLDPID} | grep ${SCRIPTNAME}`  

  if [ -n "${RESULT}" ]; then
logger -s ${SCRIPTNAME} already running! Exiting
exit 255
  fi
   fi
fi

## Update pid file
PID=`ps -ef | grep ${SCRIPTNAME} | head -n1 | awk ' {print $2;} '`
echo ${PID} > ${PIDFILE}

logger -s filter done, starting offlineimap
offlineimap -l /home/vasile/.offlineimap/log
logger -s offlineimap done, starting mail filter
mairix --unlock
/home/vasile/bin/mail_filter.py
logger -s mail filter done, starting notmuch tagger
/home/vasile/bin/notmuch-tag.sh > /home/vasile/var/log/notmuch
logger -s notmuch tagger done sync_email finished

## clean up pid file and dir
if [ -f ${PIDFILE} ]; then
rm -rf ${PIDDIR}
fi

[notmuch] envelope-to

[Tim Stoakes]

James Vasile(james at hackervisions.org)@240210-14:59:
> 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.

I'm very new here, but I think the answer is 'no' - notmuch only seems
to index a few headers. Which is a pity - I use an extensive system of
X-Label headers, and would like to convert them to notmuch tags - I just
can't seem to do it. I hope I'm wrong.

Tim

-- 
Tim Stoakes

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

[Sebastian Spaeth]

I cannot comment on this patch, I just want to state that this
functionality can also be achieved with (id:87sk90ragj.fsf at jhu.edu)
"add functionality in notmuch search mode to add or remove tags by region"
and (id:1266408746-28549-1-git-send-email-Sebastian at SSpaeth.de)
"bind 'd' to new function notmuch-search-delete-thread-or-region"

I think that "add functionality in notmuch search mode to add or remove
tags by region" might be wanted functionality anyway.

Sebastian

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

[Sebastian Spaeth]

On Wed, 24 Feb 2010 14:20:27 -0500, Jameson Rollins  wrote:
> On Wed, 24 Feb 2010 10:26:47 -0800, Carl Worth  wrote:

> > > 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.

Well, it is fatal in the sense that it makes that function useless. But
it's not as bad as it is currently unused. You will only notice it if you
make the "skip to next unread" (interactive) and bind it to a key (which
is what I have done). I still think it's worth taking this patch and fixing it 
then.

The solutions I can see are: 
- split into a "notmuch-show-next-message"
  and a notmuch-show-show-next-message (what a naming!) function. 
  One would merely skip to the next and one actually show and mark unread.
- Introduce a second argument option whether we should mark as unread or not.
- rework "notmuch-show-next-unread-message" to not make use of
  "notmuch-show-next-message" but e.g. to just use
  "notmuch-show-find-next-message" or so.

Does this make any sense?

> 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?

Touch?. As explained above. I made it interactive and bound it to 'n'.

Sebastian

[notmuch] Introducing notmuchsync

[Sebastian Spaeth]

On Wed, 24 Feb 2010 13:49:44 -0500, Jameson Rollins  wrote:
> On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth  wrote:
> > 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.

It's a fine line and depends a lot on how people actually use
notmuch. One thing that I would strongly advocate is to take on the
"respect maildir flags when importing with notmuch new" patch. This
enables me to use webmail/thunderbird (my mom at my home place is curiously 
still
refusing to switch to notmuch) etc.

As for the rest, I'd agree that we can be conservative in accepting new
notmuch features (part of its appeal is that its so darn simple) while
trying to make things easier for an ecosystem of surrounding apps.

> 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.

It's slow for deleting messages? That would surprise me, as it only
needs to parse/look at messages with a 'delete' or 'maildir::trashed'
tag.
Syncing from notmuch to maildir flags *is* slow. Limiting the output
to filenames will help greatly there (I hope). However by design it
needs to compare tags from *all* your messages with the corresponding
file name as stored in notmuch. I have no solution as how to make this
easier, at least not without adding a "needsync" tag or so when "deleting, 
replying,
reading, etc".

Sebastian

[notmuch] Introducing notmuchsync

[Sebastian Spaeth]

On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth  wrote:
> On Mon, 18 Jan 2010 16:12:28 +0100, "Sebastian Spaeth"  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.

No problem. It was just an itch I had :-). I have to say that I stopped
using the --revsync (change notmuch tags based on maildir flags) as I am
using the patch that does that from within "notmuch new" and which is
much faster than any external script could be.

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

I am fine with hosting it in contrib or on github whatever others
prefer.

> >  - 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.

JSON will definitely help. I need to investigate that, and --output will
make help performance. So yes, these are good changes from a 3rd party
perspective. I was thinking of interfacing notmuch.so directly but as
long as the python bindings are still in development, I am not going to
look at this option.

> 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'll comment on that in JRollins reply in a second :).
Sebastian

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

[James Vasile]

At Thu, 25 Feb 2010 11:53:14 +0100,
Sebastian Spaeth 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? [...]Why should it modify any 
> > other
> > tags?  A message/thread should be allowed to be both deleted and in the
> > inbox.
> 
> As long as deleted threads/messages show up in the default views, I
> don't want them to show up in my inbox or show up as unread. I agree
> that it might be possible to have "unread" yet "delete"d emails. But in
> reality, if I delete a message I don't want it to pop up in my inbox.
> 
> Feel free to apply patches however you want though, thanks to emacs,
> I'll be able to get my desired behavior nonetheless :).
> 
> > As for "unread", I think that should be handled by actually reading the
> > message, not by manually applying a state to it.
> 
> I agree, but deleting a message in my world view resets the unread tag
> (as in, I don't want to read it anymore).

This elisp might help.  I run these when deleting messages in search
or show modes.  Basically, this means I never see deleted threads
again.  I also use these to mark spam.

(defun notmuch-tags-strip-properties (tags)
  "return list of tags with emacs text properties removed

tags is a list of tags where each tag is a string with emacs text
properties
"
  (mapcar '(lambda (tag)
(set-text-properties 0 (length tag) nil tag)
tag)
  tags))

(defun notmuch-show-remove-all-tags ()
  "Remove all tags from the currently selected thread."
  (apply 'notmuch-show-remove-tag
 (notmuch-tags-strip-properties (notmuch-show-get-tags

(defun notmuch-search-remove-tags ( tags)
  "Remove multiple tags from the currently selected thread."
  (mapc 'notmuch-search-remove-tag tags))

(defun notmuch-search-remove-all-tags ()
  "Remove all tags from the currently selected thread."
  (apply 'notmuch-search-remove-tags
 (notmuch-tags-strip-properties (notmuch-search-get-tags

[notmuch] patchwork test instance

[martin f krafft]

also sprach Carl Worth  [2010.02.24.2008 +0100]:
> 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?

Yes, I've automatically tagged approx. 140 patches "accepted" so
far.

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

Okay, all of those can be tagged superseeded.

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

kermit: why are there so many songs about rainbows?
fozzy: that's part of what rainbows do.

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/20100225/d1283b69/attachment.pgp>

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

[ra...@free.fr]

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 
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 ( 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"))
+  , at 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 
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 

Re: [notmuch] Introducing notmuchsync

[Sebastian Spaeth]

On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth cwo...@cworth.org wrote:
 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.

No problem. It was just an itch I had :-). I have to say that I stopped
using the --revsync (change notmuch tags based on maildir flags) as I am
using the patch that does that from within notmuch new and which is
much faster than any external script could be.
 
 Let me know if you'd like to host this within the contrib directory of
 the notmuch repository.

I am fine with hosting it in contrib or on github whatever others
prefer.
 
   - 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.

JSON will definitely help. I need to investigate that, and --output will
make help performance. So yes, these are good changes from a 3rd party
perspective. I was thinking of interfacing notmuch.so directly but as
long as the python bindings are still in development, I am not going to
look at this option.

 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'll comment on that in JRollins reply in a second :).
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Introducing notmuchsync

[Sebastian Spaeth]

On Wed, 24 Feb 2010 13:49:44 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth cwo...@cworth.org wrote:
  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.

It's a fine line and depends a lot on how people actually use
notmuch. One thing that I would strongly advocate is to take on the
respect maildir flags when importing with notmuch new patch. This
enables me to use webmail/thunderbird (my mom at my home place is curiously 
still
refusing to switch to notmuch) etc.

As for the rest, I'd agree that we can be conservative in accepting new
notmuch features (part of its appeal is that its so darn simple) while
trying to make things easier for an ecosystem of surrounding apps.

 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.

It's slow for deleting messages? That would surprise me, as it only
needs to parse/look at messages with a 'delete' or 'maildir::trashed'
tag.
Syncing from notmuch to maildir flags *is* slow. Limiting the output
to filenames will help greatly there (I hope). However by design it
needs to compare tags from *all* your messages with the corresponding
file name as stored in notmuch. I have no solution as how to make this
easier, at least not without adding a needsync tag or so when deleting, 
replying,
reading, etc.

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

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

[Sebastian Spaeth]

On Wed, 24 Feb 2010 14:20:27 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Wed, 24 Feb 2010 10:26:47 -0800, Carl Worth cwo...@cworth.org wrote:

   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.

Well, it is fatal in the sense that it makes that function useless. But
it's not as bad as it is currently unused. You will only notice it if you
make the skip to next unread (interactive) and bind it to a key (which
is what I have done). I still think it's worth taking this patch and fixing it 
then.

The solutions I can see are: 
- split into a notmuch-show-next-message
  and a notmuch-show-show-next-message (what a naming!) function. 
  One would merely skip to the next and one actually show and mark unread.
- Introduce a second argument option whether we should mark as unread or not.
- rework notmuch-show-next-unread-message to not make use of
  notmuch-show-next-message but e.g. to just use
  notmuch-show-find-next-message or so.

Does this make any sense?

 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?

Touché. As explained above. I made it interactive and bound it to 'n'.

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

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

[Sebastian Spaeth]

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? [...]Why should it modify any 
 other
 tags?  A message/thread should be allowed to be both deleted and in the
 inbox.

As long as deleted threads/messages show up in the default views, I
don't want them to show up in my inbox or show up as unread. I agree
that it might be possible to have unread yet deleted emails. But in
reality, if I delete a message I don't want it to pop up in my inbox.

Feel free to apply patches however you want though, thanks to emacs,
I'll be able to get my desired behavior nonetheless :).

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

I agree, but deleting a message in my world view resets the unread tag
(as in, I don't want to read it anymore).

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

Re: [notmuch] envelope-to

[Sebastian Spaeth]

On Thu, 25 Feb 2010 12:00:37 +1030, Tim Stoakes notm...@stoakes.net wrote:
  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.
 
 I'm very new here, but I think the answer is 'no' - notmuch only seems
 to index a few headers. Which is a pity - I use an extensive system of
 X-Label headers, and would like to convert them to notmuch tags - I just
 can't seem to do it. I hope I'm wrong.

It's not yet possible, but it's on Carl's list of required features. I
want my spam headers being recognized as well. :-)

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

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

[James Vasile]

At Thu, 25 Feb 2010 11:53:14 +0100,
Sebastian Spaeth wrote:
 
 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? [...]Why should it modify any 
  other
  tags?  A message/thread should be allowed to be both deleted and in the
  inbox.
 
 As long as deleted threads/messages show up in the default views, I
 don't want them to show up in my inbox or show up as unread. I agree
 that it might be possible to have unread yet deleted emails. But in
 reality, if I delete a message I don't want it to pop up in my inbox.
 
 Feel free to apply patches however you want though, thanks to emacs,
 I'll be able to get my desired behavior nonetheless :).
 
  As for unread, I think that should be handled by actually reading the
  message, not by manually applying a state to it.
 
 I agree, but deleting a message in my world view resets the unread tag
 (as in, I don't want to read it anymore).

This elisp might help.  I run these when deleting messages in search
or show modes.  Basically, this means I never see deleted threads
again.  I also use these to mark spam.

(defun notmuch-tags-strip-properties (tags)
  return list of tags with emacs text properties removed

tags is a list of tags where each tag is a string with emacs text
properties

  (mapcar '(lambda (tag)
(set-text-properties 0 (length tag) nil tag)
tag)
  tags))

(defun notmuch-show-remove-all-tags ()
  Remove all tags from the currently selected thread.
  (apply 'notmuch-show-remove-tag
 (notmuch-tags-strip-properties (notmuch-show-get-tags

(defun notmuch-search-remove-tags (rest tags)
  Remove multiple tags from the currently selected thread.
  (mapc 'notmuch-search-remove-tag tags))

(defun notmuch-search-remove-all-tags ()
  Remove all tags from the currently selected thread.
  (apply 'notmuch-search-remove-tags
 (notmuch-tags-strip-properties (notmuch-search-get-tags
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[racin]

Carl: The patch in the mail has problems; apparently I have to manually add 
scissorlines to the mail for it
to be processed by git-am. I thought this was automatically added. (I hate the 
git UI -- nothing is consistent,
concepts have different names, the definition of scissor lines is as precise as 
A line that mainly consists of scissors (either 8 or 8) and perforation 
(dash -) --, but I guess we can get used to it after a while...)

I'll send you a proper patch as soon as I can. Meanwhile, I'm sure you have 
comments on this updated patch!

Matthieu

À: Carl Worth cwo...@cworth.org
Cc: notmuch@notmuchmail.org
Envoyé: Jeudi 25 Février 2010 00h00:04 GMT +00:00 GMT - Grande-Bretagne, 
Irlande, Portugal
Objet: Re: [notmuch] [PATCH] Support for deletion (patch included)

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)
 

[notmuch] Initial tagging

[James Vasile]

I'm slowly groping my way to using the notmuch emacs client as my
routine MUA.  As I coerce it into tagging and displaying the way I want,
the next big question was automatically tagging things and getting them
in to notmuch.

I'm curious as to what people are doing in this regard.

My solution involves cron running a sync_email script.  Sync_email does
the correct dance to make sure it only ever runs one instance at a time.
It also logs to syslog.  The script runs offlineimap, a mail_filter
script that sorts mail in maildirs (for wanderlust, the MUA I'm hoping
to leave behind), and then finally a shell script to do notmuch new and
initial tagging.

The tagging script uses the inbox tag to identify new mail, tags it
according to criteria, then removes the inbox tag from anything it found
a match for.  Uncategorized mail keeps the inbox tag so I can inspect it
later and make rules for it (or tag it manually).

Also, prepending tag:inbox and to search criteria restricts the
tagging to a small subset of the db, which makes the tagging script run
fairly quickly.  My unexpurgated tagging script has almost 100 rules for
tagging, and I expect it to grow over time.

## notmuch-tag.sh 
#!/bin/bash

bin=/usr/local/bin/notmuch

function notmuch {
echo $1
while [ 1 -gt 0 ]; do
result=`$bin $1 21` 
regex=already locked

if [[ $result =~ $regex ]]; then
echo Xapian DB busy.  Retrying in 2 seconds
else
if [ -n $result ]; then
echo $result
fi
return
fi

sleep 2
done
}

function tag_new { notmuch tag $1 tag:inbox and ($2); }
function blacklist { tag_new -inbox -unread +delete $1; }

notmuch new

blacklist from:x...@example.com or from y...@example.com

# voicemail
tag_new -inbox +voicemail  from:a...@example.com

# friends
tag_new +friend +mathieu mathieu or ejm2106 or em...@example.com
tag_new +friend +balktick balktick

# open community services
tag_new +ocs open community services or opencommunityservices
   
# okos
tag_new +okos jim and glaser and not LinkedIn
tag_new +okos joshlevy...@example.com
tag_new +okos enri...@example.com

# book liberator
tag_new +bklib w...@example.com or bkrpr

# joomla
tag_new +osm from:waring or to:waring
tag_new +osm from:dave.huelsm...@example.com or 
to:dave.huelsm...@example.com
tag_new +osm james.vas...@example.com
tag_new +osm joomla

#lists
tag_new +list +notmuch to:notmuchmail.org or notmuch
tag_new +list +stumpwm to:stumpwm-de...@nongnu.org or stumpwm
tag_new +list +bklib to:bk...@googlegroups.com
   
## Catchalls for sflc, hv, etc.
tag_new +sflc not tag:list and not tag:friend and softwarefreedom.org and 
not tag:osm
tag_new +sflc to:f...@example.com
tag_new +hv hackervisions.org and not tag:list and not tag:friend
tag_new +gmail (to:jvas...@example.com or from:jvas...@example.com) and not 
tag:list and not tag:friend

## Mark mine unread
tag_new -unread from:ja...@example.com
tag_new -unread from:vas...@example.com
tag_new -unread from:james.vas...@example.com

## Remove inbox tag
tag_new -inbox tag:sflc or tag:hv or tag:list or tag:osm or tag:okos or 
tag:friend or tag:bklib


# sync_email #
#!/bin/sh

## Sync email unless we're already in the process of syncing.

SCRIPTNAME=`basename $0`
PIDDIR=/home/vasile/var/run/${SCRIPTNAME}
PIDFILE=${PIDDIR}/${SCRIPTNAME}.pid

## Do the double-lock with a dir and a pid file
if ! mkdir ${PIDDIR} 2/dev/null; then

   sleep 3 # give the other process time to write its pid

   if [ -f ${PIDFILE} ]; then
  #verify if the process is actually still running under this pid
  OLDPID=`cat ${PIDFILE}`
  RESULT=`ps -ef | grep ${OLDPID} | grep ${SCRIPTNAME}`  

  if [ -n ${RESULT} ]; then
logger -s ${SCRIPTNAME} already running! Exiting
exit 255
  fi
   fi
fi

## Update pid file
PID=`ps -ef | grep ${SCRIPTNAME} | head -n1 | awk ' {print $2;} '`
echo ${PID}  ${PIDFILE}

logger -s filter done, starting offlineimap
offlineimap -l /home/vasile/.offlineimap/log
logger -s offlineimap done, starting mail filter
mairix --unlock
/home/vasile/bin/mail_filter.py
logger -s mail filter done, starting notmuch tagger
/home/vasile/bin/notmuch-tag.sh  /home/vasile/var/log/notmuch
logger -s notmuch tagger done sync_email finished

## clean up pid file and dir
if [ -f ${PIDFILE} ]; then
rm -rf ${PIDDIR}
fi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Initial tagging

[Carl Worth]

On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile ja...@hackervisions.org 
wrote:
 I'm curious as to what people are doing in this regard.

I'm currently using a script that does tagging not entirely unlike
yours, (though my script isn't clever to retry a call to
notmuch---believe it or not I'm just calling it manually still, not from
cron).

 The tagging script uses the inbox tag to identify new mail, tags it
 according to criteria, then removes the inbox tag from anything it found
 a match for.  Uncategorized mail keeps the inbox tag so I can inspect it
 later and make rules for it (or tag it manually).

One distinction is that I have all of my notmuch tag commands operate
globally rather than just on new messages. One of the things that really
annoyed be about sup was that the support for automatic tagging worked
as a hook on messages as they were processed. So I couldn't use any of
the tags for searches prior to the time that I had added a particular
tag rule. I definitely didn't want to replicate that bug.

I also don't remove the inbox tag from matched mail, since I have a
notmuch-folders configuration that takes advantage of the matched tags
in concert with the inbox tag.

I've included my current auto-tagging script (notmuch-poll) below, as
well as the snippet of my .emacs that sets my notmuch-folders variable.

 Also, prepending tag:inbox and to search criteria restricts the
 tagging to a small subset of the db, which makes the tagging script run
 fairly quickly.  My unexpurgated tagging script has almost 100 rules for
 tagging, and I expect it to grow over time.

To do my global searches quickly, I do a similar subsetting, but it's
much simpler. If I'm adding the notmuch tag I do and not
tag:notmuch. We've even had the proposal of making notmuch tag do
that automatically.

Meanwhile, I'm planning on eventually moving entirely away from any tags
that are driven entirely by searches like this. Instead, I'd like to
just have good support for saved searches where we have some syntax to
perform string expansion on configured search terms. So where I'm
currently doing:

notmuch search tag:notmuch

I could instead do:

notmuch search query:notmuch

with a configuration associating notmuch to to:notmuchmail.org and
the above would expand to:

notmuch search '(' to:notmuchmail.org ')'

We've been talking about these saved searches for a while, but we
haven't implemented them yet, (nor decided firmly on the syntax we
want). I just noticed today that sup recently added a similar
saved-search feature with the following syntax:

notmuch search {notmuch}

I think I might like something like that with more custom syntax, (since
the existing prefix: syntax has a fairly standard meaning that doesn't
fit well with this new feature.

With saved-search support in notmuch, I could get rid of my notmuch-poll
script almost entirely, (I'd still want something to automatically
remove the -inbox tag from some messages, but that's about it).

-Carl

# notmuch-poll #
echo Importing new mail
notmuch new

echo Running global tag additions to tag new mail

# Tag bug-mail first, (since we use the bugs tag below)
notmuch tag +bugs from:bugzilla-daemon and not tag:bugs

# Note mail sent specifically to me (excluding bug mail)
notmuch tag +to-me to:cwo...@cworth.org and not tag:to-me and not tag:bugs
notmuch tag +to-me to:c...@theworths.org and not tag:to-me and not tag:bugs
notmuch tag +to-me to:carl.d.wo...@intel.com and not tag:to-me and not tag:bugs

# And note all mail sent from me
notmuch tag +sent from:cwo...@cworth.org and not tag:sent
notmuch tag +sent from:c...@theworths.org and not tag:sent
notmuch tag +sent from:carl.d.wo...@intel.com and not tag:sent

# Intel mail deserves some distinction
notmuch tag +intel to:carl.d.wo...@intel.com and not tag:intel
notmuch tag +intel from:intel.com and not tag:intel
notmuch tag +intel to:intel-gfx and not tag:intel
notmuch tag +intel to:linux-gfx and not tag:intel

# Next, various free-software projects tagged by recipient
notmuch tag +cairo to:cairographics.org and not tag:cairo
notmuch tag +cairo to:pix...@lists.freedesktop.org and not tag:cairo
notmuch tag +xorg-board to:foundation.x.org and not tag:xorg-board
notmuch tag +xorg to:xorg and not tag:xorg
notmuch tag +xorg to:xcb and not tag:xorg
notmuch tag +announce to:annou...@lists.debian.org and not tag:announce
notmuch tag +debian to:lists.debian.org and not tag:debian
notmuch tag +sup to:sup-de...@rubyforge.org and not tag:sup
notmuch tag +lca to:lists.lca2010.org.nz and not tag:lca
notmuch tag +notmuch to:notmuchmail.org and not tag:notmuch
notmuch tag +nickle to:nickle.org and not tag:nickle
notmuch tag +meego '( to:d...@moblin.org or to:d...@lists.moblin.org or 
to:meego-...@meego.com )' and not tag:meego

# Finally, a few subject-based tags
notmuch tag +intel subject:xf86-video-intel and not tag:intel
notmuch tag +sup subject:sup-talk and not tag:sup
notmuch tag +pdx subject:pdx 

Re: [notmuch] vim client

[Ben Gamari]

Excerpts from Arian Kuschki's message of Thu Feb 25 12:03:30 -0500 2010:
 On Sat 20, 12:34 -0500, Ben Gamari wrote:
 
  The real problem is all notmuch calls are synchronous. Vim unfortunately
  lacks the excellent asynchronous subprocess interface that emacs has.
  Therefore, I'm afraid the vim client is going to be just as unuable
  until someone has implemented asynchronous subprocess support.
 
 What is the problem that you are trying to solve with asynchronous 
 sub process support that you cannot solve with things like 
 ':!notmuch tag +sometag pattern ' or with using temp files and 
 :autoread for views that need to be updated regularly?
 This is a genuine question, I am just not very knowledgeable about these 
 technicalities.

The client currently processes search results so it can display only the
desired fields in the results buffer. This would make the autoread
option quite expensive. On the other hand, if you can think of a way to
avoid preprocessing results, we could probably make it work. That being
said, I think the correct solution is to simply give vim a more powerful
subprocess system. I think this represents an important shortcoming
of vim's current scripting environment.

 
 Do you think improved sub process support will ever be merged into 
 mainline vim seeing that is somewhat against the vim philosophy (or 
 isn't it?)?
 
What do you mean by the vim philosophy? It wouldn't incorporate much
additional complexity and you gain quite a bit of flexibility when you
can decouple the subprocess life-cycle from the script's flow of
execution. This was actually discussed[1] not so long ago on the vim list
and a few people of unknown import seemed to support the idea of having
more powerful subprocess infrastructure. I think it's pretty much just a
matter of finding someone with some time to spare.

  and I would
  far prefer to use notmuch from within vim than from another specialized
  application.
 
 I agree. I talked to Bart, the creator of the vim client and he said he 
 was planning to resume his work on it in April at the earliest. I would 
 really like to see a usable client before that, and I don't think there 
 is that much to do to make that happen really. There is lots of existing 
 code we can use for things like json parsing and handling MIME stuff in 
 the python standard libraries for example. If anybody wants to fork Bart's 
 repo I would 
 be happy to submit patches and test , but I lack the qualification to 
 maintain a fork myself unfortunately.

I agree that a notmuch frontend implemented in Python would be nice (although 
that
might just be the result of my having effectively zero experience
scripting with vim's native language).

- Ben


[1] http://article.gmane.org/gmane.editors.vim.devel/25108
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Initial tagging

[James Vasile]

On Thu, 25 Feb 2010 17:02:08 -0800, Carl Worth cwo...@cworth.org wrote:
 One distinction is that I have all of my notmuch tag commands operate
 globally rather than just on new messages. One of the things that really
 annoyed be about sup was that the support for automatic tagging worked
 as a hook on messages as they were processed. So I couldn't use any of
 the tags for searches prior to the time that I had added a particular
 tag rule. I definitely didn't want to replicate that bug.

Sometimes I manually override a rule-based tag.  If automatic tagging
operated on old messages, overrides could be superseded.  When I add
automatic tag rules, I first execute them manually and globally from the
command line.

 To do my global searches quickly, I do a similar subsetting, but it's
 much simpler. If I'm adding the notmuch tag I do and not
 tag:notmuch. We've even had the proposal of making notmuch tag do
 that automatically.

That sounds like a good idea.  What happened with that proposal?

 Meanwhile, I'm planning on eventually moving entirely away from any tags
 that are driven entirely by searches like this. Instead, I'd like to
 just have good support for saved searches where we have some syntax to
 perform string expansion on configured search terms. 

Saved searches is a very good idea.  I look forward to it.

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