]> git.notmuchmail.org Git - notmuch/blob - test/corpus/cur/47:2,
test: simplify T360-symbol-hiding, use nm instead of objdump
[notmuch] / 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