[notmuch] indexing mail?

2010-01-14 Thread Adrian Perez de Castro
On Thu, 14 Jan 2010 18:13:53 +0100, Arvid wrote:

> On Thu, 14 Jan 2010 09:38:00 +0100, Arvid Picciani  wrote:
> 
> > on the first run (when no .notmuch is there yet), it finds some 
> > messages, but doesn't index them either.

Yuk! I logged-in via Gmail's web interface and found that I have some new
messages which are not being picked by Notmuch.

> the offending commit is 2c4555f1a56602ff1dd55a63699810522ba4d91e
> 
> from readdir (3):
> 
>  "Currently, only some file systems (among them: Btrfs, ext2, ext3,
>  and ext4) have full  support  returning  the  file
>type in d_type.  All applications must properly handle a return
>  of DT_UNKNOWN."

I am using XFS, which always returns DT_UNKNOWN. Taking into account that
there is a good deal of people using filesystems other than the ones you
mention, and that other non-linux filesystems may also return DT_UNKNOWN,
in my opinion there should be a fall-back. I will try to post a patch
Anytime Soon?.

Also, I have the feeling that the "d_type" field from "struct dirent" may
not be available in some OSes because it is a BSD extension.

Cheers,

-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100114/c182949a/attachment.pgp>


[notmuch] SWIG (and particularly Python) bindings

2009-12-30 Thread Adrian Perez de Castro
On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote:

> Regardless, I thought it might be nice to have access to the notmuch
> backend from a language other than C (preferably my high-level language
> of choice, python) [...]

Funny, I was just doing the same: a Python binding. Haha, so now we have
two just-backed Python bindings. What should we do?

> [...] To this end, I took a few hours today acquainting
> myself with SWIG and produced these bindings for Python. Unfortunately,
> it doesn't appear that SWIG has particularly good support for
> object-oriented C [...]

I already used SWIG sometimes in the past (and did not like it a lot), so
my binding is using Cython [*] (which is exactly like Pyrex plus some extra
features), so the binding is partly manual.

> While the bindings are currently in the form of a patch to notmuch
> (creating a top-level swig directory in the source tree), they could
> certainly be moved out-of-tree if the powers that be don't feel it
> appropriate to include them. [...]

Same here, see attached patch. It is currently unfinished, and I was just
about to add support for iterating notmuch_threads_t and other similar
structures. I can also publish a Git repo with the entire branch, just
drop me a line if you want me to do that.

> [...] Unfortunately, the build system is currently almost entirely
> independent from the notmuch build system. If  these are to be
> included in-tree, I would be curious to hear people have
> to say about how we might integrate it into the sup build system.
  ^^^
(Mmmh, I suppose you mean "notmuch build system" there :P)

Mine is a little more cooked, as I have added a distutils "setup.py"
script. The bad news is that Python modules need to be compiled as
relocatable object files (-fPIC to teh rescue!), and the linker will
refuse to link the generated code with "notmuch.a" -- so I am instructing
distutils to compile *all* sources again. Not nice.

BTW, I think that if more bindings start to appear, Notmuch might be built
as a shared library, to avoid duplicating it everywhere. One option may be
using *just* libtool but not the rest of auto-foo tools (for the record:
I agree with Carl that they are slow and wicked).

Regards,


[*] http://www.cython.org/
-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: notmuch-python-wip.patch
Type: text/x-patch
Size: 16874 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091230/c367e416/attachment-0001.bin>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091230/c367e416/attachment-0001.pgp>


Re: [notmuch] SWIG (and particularly Python) bindings

2009-12-30 Thread Adrian Perez de Castro
On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote:

 Regardless, I thought it might be nice to have access to the notmuch
 backend from a language other than C (preferably my high-level language
 of choice, python) [...]

Funny, I was just doing the same: a Python binding. Haha, so now we have
two just-backed Python bindings. What should we do?

 [...] To this end, I took a few hours today acquainting
 myself with SWIG and produced these bindings for Python. Unfortunately,
 it doesn't appear that SWIG has particularly good support for
 object-oriented C [...]

I already used SWIG sometimes in the past (and did not like it a lot), so
my binding is using Cython [*] (which is exactly like Pyrex plus some extra
features), so the binding is partly manual.

 While the bindings are currently in the form of a patch to notmuch
 (creating a top-level swig directory in the source tree), they could
 certainly be moved out-of-tree if the powers that be don't feel it
 appropriate to include them. [...]

Same here, see attached patch. It is currently unfinished, and I was just
about to add support for iterating notmuch_threads_t and other similar
structures. I can also publish a Git repo with the entire branch, just
drop me a line if you want me to do that.

 [...] Unfortunately, the build system is currently almost entirely
 independent from the notmuch build system. If  these are to be
 included in-tree, I would be curious to hear people have
 to say about how we might integrate it into the sup build system.
  ^^^
(Mmmh, I suppose you mean notmuch build system there :P)

Mine is a little more cooked, as I have added a distutils setup.py
script. The bad news is that Python modules need to be compiled as
relocatable object files (-fPIC to teh rescue!), and the linker will
refuse to link the generated code with notmuch.a -- so I am instructing
distutils to compile *all* sources again. Not nice.

BTW, I think that if more bindings start to appear, Notmuch might be built
as a shared library, to avoid duplicating it everywhere. One option may be
using *just* libtool but not the rest of auto-foo tools (for the record:
I agree with Carl that they are slow and wicked).

Regards,


[*] http://www.cython.org/
-- 
Adrian Perez de Castro ape...@igalia.com
Igalia - Free Software Engineering
 Makefile  |1 +
 python/.gitignore |2 +
 python/Makefile   |6 +
 python/Makefile.local |   15 ++
 python/notmuch.pyx|  397 +
 python/pyutil.h   |   16 ++
 python/setup.py   |   89 +++
 7 files changed, 526 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 021fdb8..081d670 100644
--- a/Makefile
+++ b/Makefile
@@ -37,6 +37,7 @@ include Makefile.config
 
 include lib/Makefile.local
 include compat/Makefile.local
+include python/Makefile.local
 include Makefile.local
 
 # The user has not set any verbosity, default to quiet mode and inform the
diff --git a/python/.gitignore b/python/.gitignore
new file mode 100644
index 000..7f0efa8
--- /dev/null
+++ b/python/.gitignore
@@ -0,0 +1,2 @@
+notmuch.c
+build/
diff --git a/python/Makefile b/python/Makefile
new file mode 100644
index 000..e1e5c43
--- /dev/null
+++ b/python/Makefile
@@ -0,0 +1,6 @@
+
+all: python
+
+%:
+	make -C .. $@
+
diff --git a/python/Makefile.local b/python/Makefile.local
new file mode 100644
index 000..140a701
--- /dev/null
+++ b/python/Makefile.local
@@ -0,0 +1,15 @@
+dir=python
+
+python: $(dir)/build/.stamp
+	(cd $(dir)  python setup.py build)
+	touch $@
+
+$(dir)/build/.stamp: lib/notmuch.a
+
+clean: clean-python
+
+clean-python:
+	$(RM) -r $(dir)/build
+
+.PHONY: clean-python python
+
diff --git a/python/notmuch.pyx b/python/notmuch.pyx
new file mode 100644
index 000..f38b719
--- /dev/null
+++ b/python/notmuch.pyx
@@ -0,0 +1,397 @@
+#! /usr/bin/env python
+# -*- coding: utf-8 -*-
+# vim: fenc=utf-8 ft=pyrex
+#
+# Copyright © 2009 Adrian Perez ape...@igalia.com
+#
+# Distributed under terms of the GPLv3 license.
+#
+
+cdef extern from talloc.h:
+	void* talloc_init(char *fmt, ...)
+	int   talloc_free(void *ctx)
+
+
+cdef extern from pyutil.h:
+	#
+	# Utility macros
+	#
+	char** pyutil_alloc_strv(void *ctx, unsigned nitems)
+
+
+cdef extern from notmuch.h:
+	#
+	# Return status handling
+	#
+	ctypedef enum notmuch_status_t:
+		NOTMUCH_STATUS_SUCCESS
+		NOTMUCH_STATUS_OUT_OF_MEMORY
+		NOTMUCH_STATUS_READONLY_DATABASE
+		NOTMUCH_STATUS_XAPIAN_EXCEPTION
+		NOTMUCH_STATUS_FILE_ERROR
+		NOTMUCH_STATUS_FILE_NOT_EMAIL
+		NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID
+		NOTMUCH_STATUS_NULL_POINTER
+		NOTMUCH_STATUS_TAG_TOO_LONG
+		NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW
+
+	char* notmuch_status_to_string(notmuch_status_t status)
+
+	#
+	# notmuch_database_* - notmuch.Database
+	#
+	ctypedef enum notmuch_database_mode_t:
+		NOTMUCH_DATABASE_MODE_READ_ONLY
+		NOTMUCH_DATABASE_MODE_READ_WRITE
+
+	ctypedef enum notmuch_sort_t

[notmuch] Requires g++, and something else?

2009-12-01 Thread Adrian Perez de Castro
On Tue, 1 Dec 2009 00:01:16 +, Scot wrote:

> Friends,
> 
> I'm a brand new joiner to notmuch ('course so is nearly everyone).
> 
> I just tried compiling, and I see:
> 
> 1.  g++ is also a 'dependency' though ./configure didn't catch it.
> 2.  I 'make' breaks with the following error:
> .
>   CXX lib/thread.o
>   AR  lib/notmuch.a
>   CXX notmuch
> /usr/bin/ld: cannot find -lz
> collect2: ld returned 1 exit status
> make: *** [notmuch] Error 1
> 
> This is a just-now git clone on a Ubuntu 9.10 machine which doesn't
> happen to have too much dev stuff loaded.
> Feel free to ignore this if it's been reported or it's otherwise 'known'

This is because you will need the development package for zlib, package
name is "zlib1g-dev", once you have the devel packages listed in the
README file plus this one you shoule be able of building NotMuch
successfully.

Good luck, and best regards,

-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091201/2b4e110e/attachment.pgp>


[notmuch] [PATCH] Support for printing file paths in new command

2009-11-23 Thread Adrian Perez de Castro
On Mon, 23 Nov 2009 01:24:09 +0100, Carl wrote:

> On Sat, 21 Nov 2009 01:17:18 +0100, Adrian Perez  wrote:
> > For very large mail boxes, it is desirable to know which files are being
> > processed e.g. when a crash occurs to know which one was the cause. Also,
> > it may be interesting to have a better idea of how the operation is
> > progressing when processing mailboxes with big messages.
> > 
> > This patch adds support for printing messages as they are processed by
> > "notmuch new":
> 
> Hey, that's pretty nice.

Thanks!

As a small improvement, I will send another patch in a while, which will
avoid sending ANSI escapes when output is not a terminal, and print one
file path per line in that case.

> I've pushed this now, (and I'm almost tempted to make it the
> default...).

IMHO it would be nice to have the messages-per-second information as
well in verbose mode before making it the default. I think I could cook
up a patch for that, but printing messages-per-second would mean calling
gettimeofday() for each processed file. Do you think that will be
acceptable from a performance POV? (Of course using silent mode would
still only call it once per second).

Regards,

-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091123/aba0f79c/attachment.pgp>


[notmuch] Segfault searching for tags

2009-11-19 Thread Adrian Perez de Castro
On Wed, 18 Nov 2009 12:00:10 -0600, Jeffrey wrote:

> Getting the following segfault with 306635c2 on Fedora 12.  Seems to
> be happening with any 'tag:' search that returns results.  For
> example, 'notmuch search tag:inbox' and 'notmuch search tag:unread'
> segfault but 'notmuch search tag:nosuchtag', 'notmuch search
> subject:logwatch' and 'notmuch search video' seem to work fine.
> 
> Core was generated by `/usr/bin/notmuch search --sort=oldest-first tag:inbox'.
> Program terminated with signal 11, Segmentation fault.
> \#0  Xapian::TermIterator::operator* (this=)
> at api/omtermlistiterator.cc:78
> 78RETURN(internal->get_termname());
> Current language:  auto
> The current source language is "auto; currently c++".

I have hit what I believe is exactly the same problem. In my case, some
results are printed when I execute "notmuch search tag:inbox", and then
the program crashes in the same exact place.

The thing is that in notmuch_message_get_in_reply_to(), line 288, a NULL
instance of Xapian::TermIterator is dereferenced. In my particular case,
the culpript is a cache file of Claws-Mail, as seen in the following GDB
session:

Program received signal SIGSEGV, Segmentation fault.
Xapian::TermIterator::operator* (this=) at 
api/omtermlistiterator.cc:78
78   RETURN(internal->get_termname()); Current language:  auto
The current source language is "auto; currently c++".
(gdb) bt
#0  Xapian::TermIterator::operator* (this=) at 
api/omtermlistiterator.cc:78
#1  0x0040f611 in _notmuch_message_get_in_reply_to(message=0x76dcd0) at 
lib/message.cc:288
#2  0x00412030 in _resolve_thread_relationships (thread=0x6a8b80) at 
lib/thread.cc:157
#3  0x00412454 in _notmuch_thread_create (ctx=0x65f1b0, 
notmuch=0x62d320, thread_id= 0x765530 "01b17ddb4479a0dc0b416bb63b92c43d", 
query_string=0x65f220 "tag:inbox") at lib/thread.cc:285
#4  0x00411982 in notmuch_query_search_threads (query=0x65f1b0, 
first=100, max_threads=-1) at lib/query.cc:218
#5  0x0040924d in do_search_threads (ctx=0x61f140, query=0x65f1b0, 
sort=NOTMUCH_SORT_NEWEST_FIRST, first=100, max_threads=-1) at 
notmuch-search.c:40
#6  0x004097ef in notmuch_search_command (ctx=0x61f140, argc=1, 
argv=0x7fffe188) at notmuch-search.c:164
#7  0x004066f1 in main (argc=3, argv=0x7fffe178) at notmuch.c:400
(gdb) frame 1
#1  0x0040f611 in _notmuch_message_get_in_reply_to (message=0x76dcd0) 
at lib/message.cc:288
288 in_reply_to = *i;
(gdb) p *message
$1 = {notmuch = 0x62d320, doc_id = 1, frozen = 0, message_id = 0x76db60 "", 
thread_id = 0x0, 
  in_reply_to = 0x0, filename = 0x76dc50 
"/home/aperez/.mail/inbox/.claws_cache", message_file = 0x0, 
  replies = 0x76d250, doc = {internal = {dest = 0x76d450}}}

As you can see, there "filename" points to a Claws-Mail cache file, which
is a binary file (I can provide a copy if needed). I suspect that this is
related to the fact that the iterator ends up being NULL somehow.

I will experiment a bit more with this issue -- maybe just avoiding adding
files whose name starts with a dot will suffice as temporary fix.

Cheers,

-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091119/5a6cbd02/attachment.pgp>


[notmuch] Fw: Introducing myself

2009-11-19 Thread Adrian Perez de Castro
On Thu, 19 Nov 2009 01:32:30 +0100, Adrian wrote:

> (Re-injecting this one in the list... it was my fault in reality because I
> sent two copies, one to the list and another to Carl, so he replied to me
> directly. It would have been enough to send my mail to the list -- I am
> sorry a lot for the noise)
> 
> Begin forwarded message:
> 
> Date: Thu, 19 Nov 2009 00:58:38 +0100
> From: Carl Worth 
> To: Adrian Perez de Castro 
> Subject: Re: [notmuch] Introducing myself
> 
> 
> On Wed, 18 Nov 2009 16:47:06 +0100, Adrian Perez de Castro
>  wrote:
> > On Wed, 18 Nov 2009 03:15:31 -0800, Carl wrote:
> >
> > I tried the "notmuch.el" Emacs mode, and have just installed Emacs in
> > order to be able to try it out. As I have been using Vim for the last ~9
> > years, probably that was the reason why I found it not very comfortable.
> 
> Wow, you're brave to give it a shot. And I'm glad that you were able to
> work your way through it.

After trying things a bit with some copied mailboxes, I am planning now on
moving away from Claws-Mail... so Emacs will be sitting here for a
while :D

> > I also think it would be great to have a curses-based UI, so this may
> > be a good opportunity to start doing some serious coding with it in my
> > spare time.
> 
> Sounds great. I would feel just fine seeing lots of interfaces built up
> around the notmuch search and tagging.

Me too, and all sharing the same index.

> [...] I do hope people doing custom
> interfaces will consider implementing some of the things that I happen
> to consider part of the "notmuch experience", (viewing an entire, nested
> thread at once with citations/signatures elided---this feature comes
> exactly from sup; and my magic space-bar for reading lots of mail with
> only one key---though the most important part here is to not archive a
> message until it is paged *off* the screen---as opposed to many emailers
> that mark a message as "read" as soon as any of the message appears on
> the screen).
> 
> Of course, if you're doing your own interface, then you get to do
> whatever you want. But I hope you might at least consider those ideas.

I am not totally sure about the elusion of citation and signatures, but
that can be an user setting. My favourite feature is not marking
messages as read until one decides to do so. For the rest of the lot,
I agree that they should be there as well.

Best regards,

[1] http://fdm.sourceforge.net/

-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091119/4b5eaf49/attachment-0001.pgp>


[notmuch] Fw: Introducing myself

2009-11-19 Thread Adrian Perez de Castro

(Re-injecting this one in the list... it was my fault in reality because I
sent two copies, one to the list and another to Carl, so he replied to me
directly. It would have been enough to send my mail to the list -- I am
sorry a lot for the noise)

Begin forwarded message:

Date: Thu, 19 Nov 2009 00:58:38 +0100
From: Carl Worth <cwo...@cworth.org>
To: Adrian Perez de Castro 
Subject: Re: [notmuch] Introducing myself


On Wed, 18 Nov 2009 16:47:06 +0100, Adrian Perez de Castro
 wrote:
> On Wed, 18 Nov 2009 03:15:31 -0800, Carl wrote:
>
> I tried the "notmuch.el" Emacs mode, and have just installed Emacs in
> order to be able to try it out. As I have been using Vim for the last ~9
> years, probably that was the reason why I found it not very comfortable.

Wow, you're brave to give it a shot. And I'm glad that you were able to
work your way through it.

> I showed the thing to my work mates this morning and most of them said
> that they would like to have Mutt-like keybindings *with* Not Much's
> search and tagging running behind it.

Any long-time mutt users want to suggest keybindings? I've mostly been
making stuff up as I go (with some influence from sup), but I think it's
early enough that I could still re-train my muscles. Get your votes in
now for your favorite keybindings.

> I also think it would be great to have a curses-based UI, so this may
> be a good opportunity to start doing some serious coding with it in my
> spare time.

Sounds great. I would feel just fine seeing lots of interfaces built up
around the notmuch search and tagging. I do hope people doing custom
interfaces will consider implementing some of the things that I happen
to consider part of the "notmuch experience", (viewing an entire, nested
thread at once with citations/signatures elided---this feature comes
exactly from sup; and my magic space-bar for reading lots of mail with
only one key---though the most important part here is to not archive a
message until it is paged *off* the screen---as opposed to many emailers
that mark a message as "read" as soon as any of the message appears on
the screen).

Of course, if you're doing your own interface, then you get to do
whatever you want. But I hope you might at least consider those ideas.

Happy hacking!

-Carl



-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091119/c9d3ac28/attachment.pgp>


[notmuch] Introducing myself

2009-11-18 Thread Adrian Perez de Castro
On Tue, 17 Nov 2009 18:03:17 -0800, Keith wrote:

> On Wed, 18 Nov 2009 00:20:59 +0100, Adrian Perez de Castro  igalia.com> wrote:
>
> > Also, I would like to share one idea I had in mind, that you might find
> > interesting: One thing I have found very annoying is having to re-tag my
> > mail when the indexes get b0rked (it happened a couple of times to me while
> > using Sup), so I was planning to mails as read/unread and adding the tags
> > not just to the index, but to the mail text itself, e.g. by adding a
> > "X-Tags" header field or by reusing the "Keywords" one.
> 
> Easier than that, notmuch (and sup too), provide a 'dump' command which
> just lists all of the message IDs and their associated tags. Makes
> saving tags easy and doesn't involve rewriting messages. I do this once
> a day just before my computer is backed up to an external drive.
> 
> If the index is destroyed, you can reindex the messages and then reapply
> all of the tags with 'notmuch restore'.

I already knew about "dump" and "restore", just wanted to share my
(wild) thought. I have been thinking a bit more, and if I understand
correctly the philosophy of Not Much is that it will only read my mail
and that it will never write to my mailboxes. So my idea makes no sense.
The nice thing is that I could make a script to read the index (or the
output of "notmuch dump") to add the "X-Tags" headers and mark mail :P
Taking into account this and the "do one thing well" motto: there is no
point in adding that to Not Much :)

Regards,

-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091118/e0ada2f2/attachment.pgp>


[notmuch] Introducing myself

2009-11-18 Thread Adrian Perez de Castro

Hello to all,

I have just heard about Not Much today in some random Linux-related news
site (LWN?), my name is Adrian Perez and I work as systems administrator
(although I can do some code as well :P). I have always thought that the
ideas behind Sup were great, but after some time using it, I got tired of
the oddities that it has. I also do not like doing things like having to
install Ruby just for reading and sorting mails. Some time ago I thought
about doing something like Not Much and in fact I played a bit with the
Python+Xapian and the Python+Whoosh combinations, because I find relaxing
to code things in Python when I am not working and also it is installed
by default on most distribution. I got to have some mailboxes indexed and
basic searching working a couple of months ago. Lately I have been very
busy and had no time for coding, and them... boom! Not Much appears -- and
it is almost exactly what I was trying to do, but faster. I have been
playing a bit with Not Much today, and I think it has potential.

Also, I would like to share one idea I had in mind, that you might find
interesting: One thing I have found very annoying is having to re-tag my
mail when the indexes get b0rked (it happened a couple of times to me while
using Sup), so I was planning to mails as read/unread and adding the tags
not just to the index, but to the mail text itself, e.g. by adding a
"X-Tags" header field or by reusing the "Keywords" one. This way, the index
could be totally recreated by re-reading the mail directories, and this
would also allow to a tools like OfflineIMAP [1] to get the mails into a
local maildir, tagging and indexing the mails with the e-mail reader and
then syncing back the messages with the "X-Tags" header to the IMAP server.
This would allow to use the mail reader from a different computer and still
have everything tagged finely.

Best regards,


---
[1] http://software.complete.org/software/projects/show/offlineimap

-- 
Adrian Perez de Castro 
Igalia - Free Software Engineering
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091118/88190837/attachment-0001.pgp>