24/0decf6dc792f790831baad284c55d659d98316

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 5BB9D431FBF;\r
   6         Sat, 21 Nov 2009 09:07:23 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id BRy2DldsBgM4; Sat, 21 Nov 2009 09:07:22 -0800 (PST)\r
  11 Received: from cworth.org (localhost [127.0.0.1])\r
  12         by olra.theworths.org (Postfix) with ESMTP id D5801431FAE;\r
  13         Sat, 21 Nov 2009 09:07:21 -0800 (PST)\r
  14 From: Carl Worth <cworth@cworth.org>\r
  15 To: Stefan Schmidt <stefan@datenfreihafen.org>, notmuch@notmuchmail.org\r
  16 In-Reply-To: <20091121145111.GB19397@excalibur.local>\r
  17 References: <20091121145111.GB19397@excalibur.local>\r
  18 Date: Sat, 21 Nov 2009 18:07:10 +0100\r
  19 Message-ID: <87fx874xj5.fsf@yoom.home.cworth.org>\r
  20 MIME-Version: 1.0\r
  21 Content-Type: text/plain; charset=us-ascii\r
  22 Subject: Re: [notmuch] 25 minutes load time with emacs -f notmuch\r
  23 X-BeenThere: notmuch@notmuchmail.org\r
  24 X-Mailman-Version: 2.1.12\r
  25 Precedence: list\r
  26 List-Id: "Use and development of the notmuch mail system."\r
  27         <notmuch.notmuchmail.org>\r
  28 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  29         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  30 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  31 List-Post: <mailto:notmuch@notmuchmail.org>\r
  32 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  33 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  34         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  35 X-List-Received-Date: Sat, 21 Nov 2009 17:07:23 -0000\r
  36 \r
  37 On Sat, 21 Nov 2009 15:51:11 +0100, Stefan Schmidt <stefan@datenfreihafen.org> wrote:\r
  38 > Disclaimer: I'm using vim, in combination with mutt for email, for years, but\r
  39 > never dealt with emacs. Please have this in mind and spot any emacs user errors\r
  40 > in this report. :)\r
  41 \r
  42 Hi Stefan, welcome to Notmuch! And don't worry, we don't discriminate\r
  43 (too much) against non-emacs users around here.\r
  44 \r
  45 > I have first seen notmuch several weeks ago as it seems a silent project. Being\r
  46 > more then happy now that it envolves quickly and a real developer community\r
  47 > builds around it.\r
  48 \r
  49 Yes. Notmuch was a silent project since it was just something that I was\r
  50 doing for myself. I was always writing it as free software, and even had\r
  51 a public git repository available, but hadn't advertised it at all yet.\r
  52 \r
  53 And Keith did rather catch me off guard by announcing it. But I can't\r
  54 complain as we have gotten a nice community started already, and it's\r
  55 great to have other people writing the code that I intended to\r
  56 write. :-)\r
  57 \r
  58 But it's also true that some obvious problems just aren't taken care of\r
  59 yet.\r
  60 \r
  61 > But now to my problem. Getting m mail indexed was easy enough:\r
  62 > \r
  63 > stefan@excalibur:~$ du -chs not-much-mail/\r
  64 > 1.5G    not-much-mail/\r
  65 > 1.5G    total\r
  66 > stefan@excalibur:~$ time notmuch new\r
  67 > Found 103677 total files.\r
  68 > Processed 103677 total files in 42m 30s (40 files/sec.).\r
  69 > Added 100899 new messages to the database (not much, really).\r
  70 \r
  71 Good. I'm glad that went fairly smoothly for you.\r
  72 \r
  73 Though, frankly, I think we need to fix "notmuch new" to do much better\r
  74 than 40 files/sec. One plan I have for this is to not use the database\r
  75 to search for message IDs when adding many messages---but to instead\r
  76 just use a hash-table (seeded from any messages already in the\r
  77 database). This would allow us to do all thread resolution before\r
  78 indexing messages, without having to do the N different searches, and\r
  79 also means we'd avoid continually rewriting documents when merging\r
  80 thread IDs.\r
  81 \r
  82 > I put (require  'notmuch) in my ~/.emacs ans start emacs with the -f notmuch\r
  83 > option to enter the notmuch mode.\r
  84 \r
  85 I'm glad you've figured that much out. I feel bad that that's not even\r
  86 in the documentation anywhere yet.\r
  87 \r
  88 > What happends then is that a notmuch process gets started and emacs\r
  89 > waits for the return.\r
  90 \r
  91 OK. This is a known shortcoming. As Bdale supposes, this problem is from\r
  92 notmuch trying to load and construct every thread in your\r
  93 database. There are actually several different bugs/missing features\r
  94 here that should be addressed:\r
  95 \r
  96   * "notmuch new" should look at the R flag in maildir files to\r
  97     determine that they are read and do not need to be marked as "inbox"\r
  98     and "unread"\r
  99 \r
 100   * "notmuch setup" should prompt for some date range, ("last 2 months"\r
 101     by default?) before which no messages will be considered unread.\r
 102 \r
 103 Either of those two fixes would have prevented your particular\r
 104 problem. But it's still easy to generate searches that return large\r
 105 numbers of results. So there's some more to do:\r
 106 \r
 107   * The emacs code needs to call "notmuch search" with the --first and\r
 108     --max-threads options to get a limited set of results, (one or two\r
 109     screenfuls). You should be able to test this at the command line and\r
 110     see that it returns results quickly. Then, of course, we'd like the\r
 111     emacs code to fill in subsequent screenfuls as you page.\r
 112 \r
 113 But none of that helps you right now. What you need is to retroactively\r
 114 remove all of the "inbox" and "unread" tags from messages older than\r
 115 some time period. So then there's another missing feature:\r
 116 \r
 117   * We need to support date-range-based searches. If we had that you\r
 118     could just do:\r
 119 \r
 120         notmuch tag -inbox -unread until:"2 months ago"\r
 121 \r
 122     But we don't quite have this yet. Xapian does have support for a\r
 123     slightly less convenient date range specification:\r
 124 \r
 125         1970-01-01..2009-09-21\r
 126 \r
 127     but it turns out that we can't even use that just yet, since to make\r
 128     that work we would have to have dates saved as YYYYMMDD strings for\r
 129     each message, (where instead we have time_t values stored serialized\r
 130     into a string that will sort correctly.). So we need a new\r
 131     ValueRangeProcessor class to map to timestamps, and then we'll need\r
 132     some fancy parsing to do things like "2 months ago".\r
 133 \r
 134 So, what's the best thing to do today if you want to start playing with\r
 135 notmuch? I think you could pick one of the above to work on, (a quick\r
 136 hack to "notmuch new" and a re-import might do the trick). Or you might\r
 137 just remove the inbox and unread tags from all messages and then just\r
 138 let messages that are actually *new* in the future get tagged into the\r
 139 inbox by "notmuch new". Oh, but then there's another missing feature:\r
 140 \r
 141   * We need a syntax to specify a search string that should match all\r
 142     messages. Then you could do:\r
 143 \r
 144         notmuch tag -inbox -unread <whatever-magic-we-came-up-with>\r
 145 \r
 146 Yikes! So many bugs and missing features. How is anyone actually using\r
 147 this system? Well, Keith and I were able to get past all this by simply\r
 148 doing a "notmuch restore" based on tags we got from sup-dump. So here,\r
 149 is another attempt:\r
 150 \r
 151   1. Run "notmuch dump <some-file>" to get the list of message IDs, (all\r
 152      with their "inbox" and "unread" tags).\r
 153 \r
 154   2. Edit that file to remove the tags you want.\r
 155 \r
 156   3. Run "notmuch restore <some-file>" to cause the tags to be removed.\r
 157 \r
 158 But, (*sigh*), that's not good either, because "notmuch dump" is\r
 159 currently hard-coded to dump messages in message-ID order rather than\r
 160 date order, (so you can't easily do something like "just remove the tags\r
 161 from messages older than two months).\r
 162 \r
 163 So, there's sadly no easy way to get what you want with the tools in\r
 164 their current form. I guess that's the pain that you get for being an\r
 165 early adopter. :-}\r
 166 \r
 167 But if hacking a little C code doesn't scare you away, a lot of the\r
 168 things listed above are actually really easy to fix. (Like, fixing\r
 169 "notmuch dump" to just run in date order is a one-line change. Adding a\r
 170 --sort command-line option to it wouldn't be much harder, etc.)\r
 171 \r
 172 So hopefully the above serves as a nice TODO list.\r
 173 \r
 174 Thanks everyone for your interest in this software even in its current,\r
 175 can-be-painful-to-use state.\r
 176 \r
 177 -Carl\r
 178 \r
 179 PS. Expect the mass-re-tag operations to be about as slow as the\r
 180 original "notmuch new" import of the messages. That's a known bug in\r
 181 Xapian that's one of the highest priority things that I'd like to fix,\r
 182 (along with all of the above and all the other things I want to do...)\r
 183 \r
 184 At least we're not running out of things to work on here.\r