a0/a3af4a2d07d9e40797779c398afa0af592257a

   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 E7DC0431FBC\r
   6         for <notmuch@notmuchmail.org>; Mon, 22 Feb 2010 10:29:30 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.943\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1.8, AWL=-0.144, BAYES_50=0.001] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id 1DVSRn9XIh4z; Mon, 22 Feb 2010 10:29:30 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id E870F431FAE;\r
  18         Mon, 22 Feb 2010 10:29:29 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 3E73C25427B; Mon, 22 Feb 2010 10:29:29 -0800 (PST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: Jameson Rollins <jrollins@finestructure.net>\r
  23 In-Reply-To: <87ocjjhb34.fsf@servo.finestructure.net>\r
  24 References: <87ocjjhb34.fsf@servo.finestructure.net>\r
  25 Date: Mon, 22 Feb 2010 10:29:28 -0800\r
  26 Message-ID: <871vgdgm47.fsf@yoom.home.cworth.org>\r
  27 MIME-Version: 1.0\r
  28 Content-Type: multipart/signed; boundary="=-=-=";\r
  29         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  30 Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
  31 Subject: Re: [notmuch] patch queue\r
  32 X-BeenThere: notmuch@notmuchmail.org\r
  33 X-Mailman-Version: 2.1.13\r
  34 Precedence: list\r
  35 List-Id: "Use and development of the notmuch mail system."\r
  36         <notmuch.notmuchmail.org>\r
  37 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  38         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  39 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  40 List-Post: <mailto:notmuch@notmuchmail.org>\r
  41 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  42 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  43         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  44 X-List-Received-Date: Mon, 22 Feb 2010 18:29:31 -0000\r
  45 \r
  46 --=-=-=\r
  47 \r
  48 On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins <jrollins@finestructure.net> wrote:\r
  49 > Hey, Carl.  I've noticed that you've been applying some patches that\r
  50 > were recently sent to the list, out of order from the chronological\r
  51 > queue of patches that were sent to the list.  I'm a fan of the recently\r
  52 > applied patches, but I'm curious about what your plans are for the older\r
  53 > patches in the quene.  Are you still planning on processing them?\r
  54 > Should the older patches be rebased against the current master and\r
  55 > resent?\r
  56 \r
  57 Thanks for asking, Jamie.\r
  58 \r
  59 I'm still planning on processing the entire queue, (and chronologically),\r
  60 but I'm definitely capable of being influenced to grab stuff from the\r
  61 "future"\r
  62 \r
  63 > I'm not at all trying to be pushy; there's just some older stuff in the\r
  64 > queue that I would really like to see applied, such as folder-based\r
  65 > tagging, json output, and some of the emacs UI improvements.\r
  66 \r
  67 You're not being pushy at all. Please feel free to let me know what you\r
  68 think is most important.\r
  69 \r
  70 I totally agree on the things mentioned above as being priority. I want\r
  71 folder-based tagging myself, and there are a *lot* of interesting things\r
  72 that are blocking on json output. Meanwhile, shortcomings in the emacs\r
  73 UI are causing me problems on a constant basis, (the latest thing\r
  74 driving me crazy is the regression that refreshing search results makes\r
  75 the current position in the search results get lost).\r
  76 \r
  77 For folder-based tagging, that will cause an increment in the\r
  78 database-format version, so I'd like to do a couple of other things at\r
  79 the same time. One is to enable indexing of additional headers, (spam\r
  80 flags, and mailing-list headers), and the other is to stop doing\r
  81 redundant indexing of data under multiple prefixes[*].\r
  82 \r
  83 For the emacs UI improvements, I do plan on making an early sweep of the\r
  84 patch queue and applying them, (if only because I have some improvements\r
  85 I need to make myself, and I want to avoid doing anything that's already\r
  86 been done).\r
  87 \r
  88 Thanks for your input, and please feel free to let me know your thoughts\r
  89 at any time.\r
  90 \r
  91 -Carl\r
  92 \r
  93 [*] This idea came from an equivalent fix recently made to sup. We are\r
  94 currently indexing the subject, for example, with a "subject:" prefix\r
  95 and also with no prefix, (to match search terms with no prefix). The fix\r
  96 is to just index it with the "subject:" prefix, but then at search time\r
  97 to take any un-prefixed terms and match them against a whole list of\r
  98 prefixes, (subject:, from:, to:, etc.). This should be a nice savings on\r
  99 our database size with no appreciable performance cost.\r
 100 \r
 101 \r
 102 --=-=-=\r
 103 Content-Type: application/pgp-signature\r
 104 \r
 105 -----BEGIN PGP SIGNATURE-----\r
 106 Version: GnuPG v1.4.10 (GNU/Linux)\r
 107 \r
 108 iD8DBQFLgs0J6JDdNq8qSWgRAhowAJ9x/IPqea4HkiC++CLaufzM8I5uGQCfXcpj\r
 109 1D+UObvQdLJya+Y1LOuo+0g=\r
 110 =rK6B\r
 111 -----END PGP SIGNATURE-----\r
 112 --=-=-=--\r