[notmuch] notmuch and imap [musing, no code :)]

2009-12-15 Thread Alec Berryman
David Bremner on 2009-12-15 08:05:13 -0400:

> Recent discussions on IRC (I forget with whom, sorry), brought me back
> to thinking about syncing notmuch with imap.  In addition to the flags
> \Seen, \Answered, \Draft, \Deleted, and \Flagged, imap servers can
> optionally support user defined keywords (i.e. tags). At least courier
> and dovecot do.  These keywords are imap "atoms", which, without tracing
> though the BNF [1] completely look like they can can have (ascii)
> alphanumeric, and punctuation other than brackets, quotes and "%", "*".

I am also very interested in syncing tags between computers.  I started
implementing storage of tags in message headers.  It's has been done
before - several mutt extensions and systems use X-Label.  This approach
offers several advantages to notmuch dump/restore and IMAP flags:

  - compatability: most mail clients can search on headers, so even if
you're not using notmuch full-time (squirrelmail? phone?), you can
get some benefit from it

  - works with offlineimap without further effort: no new transport
mechanism required

  - a migration path: text-based mail sorting tools like procmail can
easily set headers

  - backups are easy: you can't miss backing up your tags because
they're in the messages

There are security concerns (need to strip incoming messages of tags so
no one tags your mail for you), privacy concerns (if you forward the
entire message as an attachment, may want to strip tags), and space
concerns (how many flags?), but I think they can be worked around.

I haven't gotten very far with my implementation due to time
constraints.  It reads tags fine, but I haven't implemented writing,
which is the involved part.  I hope to get to this between Christmas and
New Years, but who knows.



[notmuch] wish: syncable/immutable threads

2009-12-15 Thread David Bremner

I write links to notmuch threads into my todo list in org-mode.

I then try to visit these threads on a different machine, but of course
that thread id doesn't exist there, since the database was reindexed and
tags reimported.

I don't know if it is in any way practical, but it would be nice from my
point of view if thread id's were a property of the mail collection, or
at least it was possible to dump and restore them.

If this is too much of a corner case, then I suspect I can work around
it in the emacs client by calling search twice, first with an id in the
thread.

David


[notmuch] Threading

2009-12-15 Thread Marten Veldthuis
On Thu, 10 Dec 2009 13:30:13 -0800, Carl Worth  wrote:
> But I still have a hard time justifying user operations to manipulate
> threading. The whole point of threading is to make it faster to process
> and read messages. But manual operations like joining and splitting
> threads seem like the user just doing more work, and that *after* having
> read the messages. So that seems mostly backwards to me.

By the way, Outlook & Exchange suck (or at least some versions do), and
don't seem to generate In-Reply-To and References: headers. Just got a
mail which prompted me to write this mail. I'd really like to be able to
join messages in a case like this.

-- 
- Marten


[notmuch] [patch] store folder information

2009-12-15 Thread Carl Worth
On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl?ckner  wrote:
> I've patched notmuch to retain information on which folder emails are stored 
> in. This makes the transition from a folders-and-procmail model somewhat 
> easier. The resulting changes are attached.

Very nice. I like this idea very much.

(We recently had discussions about automatically adding tags based on
the directories in which mail files were found, and I said I'd prefer a
solution which allowed the user to search on the directory name
instead.)

> @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
>   s++;
>   if (strncasecmp (s, "re:", 3) == 0)
>   s += 3;
> +else if (strncasecmp (s, "aw:", 3) == 0)
> + s += 3;
>   else
>   break;
>  }

This hunk looks unrelated to the rest. Could you submit that separately,
please?

> +gchar *full_folder_name = NULL;
> +gchar *folder_base_name = NULL;
> +
> +/* Find name of "folder" containing the email. */
> +full_folder_name = g_strdup(path);
> +while (1)
> +{
> +folder_base_name = g_path_get_basename(full_folder_name);

The trailing directory name is available already during the
traversal. So you don't need to search it back out again. See the patch
in the following message:

id:87fx8bygi7.fsf at linux.vnet.ibm.com

which simply passes the trailing directory name along, (but skipping a
name of "cur" or "new" while traversing).

That kind of approach looks a lot nice to me.

Beyond that, though, I imagine some people have hierarchical folders as
well, so it probably makes sense to store them as well.

To do that, it's probably just a matter of calling gen_terms on the
complete filename. I haven't tested, but doing that should allow
Xapian's phrase searching to do the right thing for something like:

filename:portion/of/the/path/name

I think something like that is what I would like to see.

-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/20091215/ffdc862b/attachment.pgp>


[notmuch] [patch] store folder information

2009-12-15 Thread Ruben Pollan
Some errors applying the patch:

[meskio at blackspot:src/notmuch.orig]$ git apply 
~/0001-Preseve-folder-information-when-indexing.patch
/home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: trailing 
whitespace.
status = notmuch_database_add_message (notmuch, next, 
/home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: trailing 
whitespace.
   folder_base_name, 
warning: 2 lines add whitespace errors.

It's just whitespaces at the end of the lines.


The patch works fine for me. I like it handles nicely the .foo.bar directories 
so I can do searches for "folder:foo" and for "folder:bar".

Reviewed-by: Ruben Pollan 

On 14:21, Mon 14 Dec 09, Andreas Kl?ckner wrote:
> I've patched notmuch to retain information on which folder emails are stored 
> in. This makes the transition from a folders-and-procmail model somewhat 
> easier. The resulting changes are attached.

-- 
Rub?n Poll?n  | jabber:meskio at jabber.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Lo que pasa es que tienes envidia
por que las vocecitas me hablan a mi.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091215/bff06cfc/attachment.pgp>


[notmuch] notmuch and imap [musing, no code :)]

2009-12-15 Thread David Bremner

Recent discussions on IRC (I forget with whom, sorry), brought me back
to thinking about syncing notmuch with imap.  In addition to the flags
\Seen, \Answered, \Draft, \Deleted, and \Flagged, imap servers can
optionally support user defined keywords (i.e. tags). At least courier
and dovecot do.  These keywords are imap atoms, which, without tracing
though the BNF [1] completely look like they can can have (ascii)
alphanumeric, and punctuation other than brackets, quotes and %, *.

So the mapping is relatively nice between notmuch tags and imap
keywords.

One idea I had was to extend some imap syncing program to sync to
notmuch. mbsync (confusingly also named isync) is a C based one. It is
indeed relatively easy to add a new backend; I made a new notmuch
driver for mbsync in an hour or so that is actually just a maildir
driver.  I am a little discouraged by some of mbsync code (there are
lots of places with a buffer hard-coded to size 16, with a comment to
change that later when keyword support is added), but in principle, I
think this could work.  A more fundamental issue is that mbsync, like
most similar programs uses an index file to keep track of the sync
state, and it seems somehow wrong (or at least fragile) to keep a second
database with essentially the same information in it.

To write a custom sync program would require some imap code; this is
somewhere between trivial and not; mbsync's imap driver is about 1900
lines of C.  There is the uw c-client library; I remember some security
issues but that was more than a decade ago.  There are some newer
libraries like tinymail and libetpan, but they seem to have a whole
bunch of stuff not needed for notmuch.

d


[1]: http://www.faqs.org/rfcs/rfc3501.html
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [patch] store folder information

2009-12-15 Thread Ruben Pollan
Some errors applying the patch:

[mes...@blackspot:src/notmuch.orig]$ git apply 
~/0001-Preseve-folder-information-when-indexing.patch
/home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: trailing 
whitespace.
status = notmuch_database_add_message (notmuch, next, 
/home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: trailing 
whitespace.
   folder_base_name, 
warning: 2 lines add whitespace errors.

It's just whitespaces at the end of the lines.


The patch works fine for me. I like it handles nicely the .foo.bar directories 
so I can do searches for folder:foo and for folder:bar.

Reviewed-by: Ruben Pollan mes...@sindominio.net

On 14:21, Mon 14 Dec 09, Andreas Klöckner wrote:
 I've patched notmuch to retain information on which folder emails are stored 
 in. This makes the transition from a folders-and-procmail model somewhat 
 easier. The resulting changes are attached.

-- 
Rubén Pollán  | jabber:mes...@jabber.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Lo que pasa es que tienes envidia
por que las vocecitas me hablan a mi.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] Threading

2009-12-15 Thread Marten Veldthuis
On Thu, 10 Dec 2009 13:30:13 -0800, Carl Worth cwo...@cworth.org wrote:
 But I still have a hard time justifying user operations to manipulate
 threading. The whole point of threading is to make it faster to process
 and read messages. But manual operations like joining and splitting
 threads seem like the user just doing more work, and that *after* having
 read the messages. So that seems mostly backwards to me.

By the way, Outlook  Exchange suck (or at least some versions do), and
don't seem to generate In-Reply-To and References: headers. Just got a
mail which prompted me to write this mail. I'd really like to be able to
join messages in a case like this.

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


[notmuch] wish: syncable/immutable threads

2009-12-15 Thread David Bremner

I write links to notmuch threads into my todo list in org-mode.

I then try to visit these threads on a different machine, but of course
that thread id doesn't exist there, since the database was reindexed and
tags reimported.

I don't know if it is in any way practical, but it would be nice from my
point of view if thread id's were a property of the mail collection, or
at least it was possible to dump and restore them.

If this is too much of a corner case, then I suspect I can work around
it in the emacs client by calling search twice, first with an id in the
thread.

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