[notmuch] Introducing myself

[Adrian Perez de Castro]

On Wed, 18 Nov 2009 03:15:31 -0800, Carl wrote:

> So I'd written a bunch of functional code, only to find myself stuck at
> the very last step, (hooking it up to the existing sup interface). Then
> Keith suggested emacs and it all seemed pretty easy since I'd already
> done all the Xapian work. So it's funny, I was only willing to commit to
> this project because I wasn't consciously aware I was working on it.
> Otherwise it would have seemed to overwhelming to start. :-)

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.
Even so, I am able of searching, sending and tagging mail quite happily.
Apart from it being a bit Spartan, the only issue I have found so far is
that I keep pushing the Escape key a lot -- which is my fault as that is a
compulsive behaviour derived of using a Vi-like editor :D

(Side note: I would not like to start an editor-religion debate, I just
want you to know that most probably it is my fault when I say that I am
not very comfortable with the Emacs mode)

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. 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.
 
> > Also, I would like to share one idea [...] 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.
> 
> It is an interesting idea. But there's also something really comforting
> about the email indexed never modifying the mail files. If you're
> reading the notmuch commit logs closely you'll see that I'm not actually
> careful enough to be trusted with your mail (but I try). So I like that
> I don't even have to trust myself---the worst that happens is that I
> have to recreate my index.

I already made a comment about this in another reply, I could make the
modifications e.g. from a script, so no need to add this in Not Much.
Moreover, I agree that if one of the goals is to never modify mailboxes,
then the current behaviour is just perfect.

> And as Keith mentioned, we've got the "notmuch dump; notmuch restore"
> idea working exactly as it did in sup. (Though I am thinking of also
> adding thread IDs to that now---more on that later.)
> 
> The big annoyance I had with sup index creation, (I ended up having to
> do it more than once too), was that it takes *forever*. Right now,
> notmuch is a little bit faster, but not a lot faster. And I've got some
> ideas to fix that. It would be really nice if index creation were pain
> free. (And maybe it is for some user with small amounts of mail---oh, to
> have only 40000 messages to have to index!).

Wow, that is a lot of mail. Definitely people having as much mail as you
(er... I mean "_not much_ mail as you") would benefit from faster
indexing.

> [*] The problem here is that sup puts serialized ruby data structures
> into the data field of its Xapian documents. So being compatible with
> sup means being able to recreate serialized data structures for a
> particular version of ruby.

Scary...

-- 
Adrian Perez de Castro <aperez at igalia.com>
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/db88b07f/attachment.pgp>