git.notmuchmail.org Git - notmuch/blob - test/corpus/cur/47:2,

   1 From: "Carl Worth" <cworth@cworth.org>
   2 To: notmuch@notmuchmail.org
   3 Date: Wed, 18 Nov 2009 03:15:31 -0800
   4 Subject: [notmuch] Introducing myself
   5 In-Reply-To: <20091118002059.067214ed@hikari>
   6 References: <20091118002059.067214ed@hikari>
   7 Message-ID: <87aaykqe24.fsf@yoom.home.cworth.org>
   8
   9 On Wed, 18 Nov 2009 00:20:59 +0100, Adrian Perez de Castro <aperez at igalia.com> wrote:
  10 > I have just heard about Not Much today in some random Linux-related news
  11 > site (LWN?), my name is Adrian Perez and I work as systems administrator
  12
  13 Welcome to notmuch, Adrian! We're glad to have you here.
  14
  15 > by default on most distribution. I got to have some mailboxes indexed and
  16 > basic searching working a couple of months ago. Lately I have been very
  17 > busy and had no time for coding, and them... boom! Not Much appears -- and
  18 > it is almost exactly what I was trying to do, but faster. I have been
  19 > playing a bit with Not Much today, and I think it has potential.
  20
  21 It's funny, because I had the exact same experience with sup a couple of
  22 months ago. I had been frustrated for years with email programs, and had
  23 been thinking about how I'd like things to work n the back of my mind
  24 for a long time, (but never *quite* getting to the point where I would
  25 commit to writing an email system myself).
  26
  27 And then... boom! I found sup and was instantly hooked. It had so much
  28 of what I had imagined, (and much of what I hadn't yet imagined) that I
  29 was quite delighted.
  30
  31 It was really quite by accident that I ended up inventing a different
  32 system. I had started out just trying to speedup index creation for sup.
  33 If I hadn't run into the problem that it was very difficult[*] to create a
  34 sup-compatible index from C code, I might have stopped there.
  35
  36 So I'd written a bunch of functional code, only to find myself stuck at
  37 the very last step, (hooking it up to the existing sup interface). Then
  38 Keith suggested emacs and it all seemed pretty easy since I'd already
  39 done all the Xapian work. So it's funny, I was only willing to commit to
  40 this project because I wasn't consciously aware I was working on it.
  41 Otherwise it would have seemed to overwhelming to start. :-)
  42
  43 Anyway, that's a lot of off-topic rambling off of your introduction. But
  44 I'm glad that notmuch can now give that same "boom!" to others, and I'm
  45 glad you see potential in it.
  46
  47 > Also, I would like to share one idea I had in mind, that you might find
  48 > interesting: One thing I have found very annoying is having to re-tag my
  49 > mail when the indexes get b0rked (it happened a couple of times to me while
  50 > using Sup), so I was planning to mails as read/unread and adding the tags
  51 > not just to the index, but to the mail text itself, e.g. by adding a
  52 > "X-Tags" header field or by reusing the "Keywords" one. This way, the index
  53 > could be totally recreated by re-reading the mail directories, and this
  54 > would also allow to a tools like OfflineIMAP [1] to get the mails into a
  55 > local maildir, tagging and indexing the mails with the e-mail reader and
  56 > then syncing back the messages with the "X-Tags" header to the IMAP server.
  57 > This would allow to use the mail reader from a different computer and still
  58 > have everything tagged finely.
  59
  60 It is an interesting idea. But there's also something really comforting
  61 about the email indexed never modifying the mail files. If you're
  62 reading the notmuch commit logs closely you'll see that I'm not actually
  63 careful enough to be trusted with your mail (but I try). So I like that
  64 I don't even have to trust myself---the worst that happens is that I
  65 have to recreate my index.
  66
  67 And as Keith mentioned, we've got the "notmuch dump; notmuch restore"
  68 idea working exactly as it did in sup. (Though I am thinking of also
  69 adding thread IDs to that now---more on that later.)
  70
  71 The big annoyance I had with sup index creation, (I ended up having to
  72 do it more than once too), was that it takes *forever*. Right now,
  73 notmuch is a little bit faster, but not a lot faster. And I've got some
  74 ideas to fix that. It would be really nice if index creation were pain
  75 free. (And maybe it is for some user with small amounts of mail---oh, to
  76 have only 40000 messages to have to index!).
  77
  78 -Carl
  79
  80 [*] The problem here is that sup puts serialized ruby data structures
  81 into the data field of its Xapian documents. So being compatible with
  82 sup means being able to recreate serialized data structures for a
  83 particular version of ruby.
  84