8f/e7c103b467b2e69c469f0250eeaf6a7efe9313

   1 Return-Path: <amdragon@mit.edu>\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 968D9431FD0\r
   6         for <notmuch@notmuchmail.org>; Wed, 13 Jul 2011 11:57:37 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 ei+Ih34cvLfA for <notmuch@notmuchmail.org>;\r
  16         Wed, 13 Jul 2011 11:57:37 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU\r
  18         [18.9.25.12])\r
  19         by olra.theworths.org (Postfix) with ESMTP id E7368431FB6\r
  20         for <notmuch@notmuchmail.org>; Wed, 13 Jul 2011 11:57:36 -0700 (PDT)\r
  21 X-AuditID: 1209190c-b7c65ae00000117c-fb-4e1deaa9a6c2\r
  22 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
  23         by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 2C.F0.04476.9AAED1E4; Wed, 13 Jul 2011 14:57:45 -0400 (EDT)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p6DIvZWc021267; \r
  27         Wed, 13 Jul 2011 14:57:36 -0400\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p6DIvW6D021713\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Wed, 13 Jul 2011 14:57:35 -0400 (EDT)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1Qh4cb-0005hQ-Rl; Wed, 13 Jul 2011 14:57:21 -0400\r
  37 Date: Wed, 13 Jul 2011 14:57:21 -0400\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Pieter Praet <pieter@praet.org>\r
  40 Subject: Re: [PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter'\r
  41 Message-ID: <20110713185721.GI25558@mit.edu>\r
  42 References: <20110705214234.GA15360@mit.edu>\r
  43         <1310416993-31031-1-git-send-email-pieter@praet.org>\r
  44         <20110711210532.GC25558@mit.edu> <878vs28dvo.fsf@praet.org>\r
  45 MIME-Version: 1.0\r
  46 Content-Type: text/plain; charset=us-ascii\r
  47 Content-Disposition: inline\r
  48 In-Reply-To: <878vs28dvo.fsf@praet.org>\r
  49 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  50 X-Brightmail-Tracker:\r
  51  H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0V35StbP4N5HNot9d7YwWVy/OZPZ\r
  52         4vfrG8wOzB67nv9l8ni26hazR8e+y6wBzFFcNimpOZllqUX6dglcGUuaowp+SVf8XfqNuYFx\r
  53         hVgXIyeHhICJROe0NewQtpjEhXvr2boYuTiEBPYxSszes4cdwtnAKPFs6XMo5ySTxOvlB5kg\r
  54         nCWMEgt6j7OC9LMIqEo8+/iICcRmE9CQ2LZ/OSOILSKgLHH6yU+wHcwCnhIvJi0BqxEW8Jbo\r
  55         W3EWrIZXQEfi35WLYHEhgcWMEnd/Z0PEBSVOznzCAtGrJXHj30ugGg4gW1pi+T8OkDCngLrE\r
  56         4/9vwU4QFVCRuLa/nW0Co9AsJN2zkHTPQuhewMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdQ\r
  57         LzezRC81pXQTIyjUOSV5djC+Oah0iFGAg1GJh5fjhKyfEGtiWXFl7iFGSQ4mJVHe8y+BQnxJ\r
  58         +SmVGYnFGfFFpTmpxYcYJTiYlUR46xuAcrwpiZVVqUX5MClpDhYlcd5y7/++QgLpiSWp2amp\r
  59         BalFMFkZDg4lCV5GYEwLCRalpqdWpGXmlCCkmTg4QYbzAA13BqnhLS5IzC3OTIfIn2JUlBLn\r
  60         FQVJCIAkMkrz4HphqegVozjQK8K8OiBVPMA0Btf9CmgwE9DgdVZgg0sSEVJSDYxxdQs/Lo/Q\r
  61         LOGUUp8WkrnqhVGHZuPPf5P+zjj1fpu/wwKrWqVbK/NUxDN87sn8rpXu5WmZySAnd75+uvbz\r
  62         N0JWx+9OiV8Q2r/o/k7nkJbX5csWcDZn+vr+vD93Lpe1cEvUzqXbjl+tf+Qn9jVxQlx+o3uE\r
  63         zZbEUDYecYabc7//73A7ONf7e6sSS3FGoqEWc1FxIgDdG6UGIAMAAA==\r
  64 Cc: Notmuch Mail <notmuch@notmuchmail.org>, David Edmondson <dme@dme.org>\r
  65 X-BeenThere: notmuch@notmuchmail.org\r
  66 X-Mailman-Version: 2.1.13\r
  67 Precedence: list\r
  68 List-Id: "Use and development of the notmuch mail system."\r
  69         <notmuch.notmuchmail.org>\r
  70 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  72 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  73 List-Post: <mailto:notmuch@notmuchmail.org>\r
  74 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  75 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  76         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  77 X-List-Received-Date: Wed, 13 Jul 2011 18:57:37 -0000\r
  78 \r
  79 Quoth Pieter Praet on Jul 13 at  4:16 pm:\r
  80 > On Mon, 11 Jul 2011 17:05:32 -0400, Austin Clements <amdragon@MIT.EDU> wrote:\r
  81 > > Quoth Pieter Praet on Jul 11 at 10:43 pm:\r
  82 > > > TL;DR: I can haz regex pl0x?\r
  83 > > \r
  84 > > Oof, what a pain.  I'm happy to change the output format of search; I\r
  85 > > hadn't realized how difficult it would be to parse.  In fact, I'm not\r
  86 > > sure it's even parsable by regexp, because the message ID's themselves\r
  87 > > could contain parens.\r
  88 > > \r
  89 > > So what would be a good format?  One possibility would be to\r
  90 > > NULL-delimit the query part; as distasteful as I find that, this part\r
  91 > > of the search output isn't meant for user consumption.  Though I fear\r
  92 > > this is endemic to the dual role the search output currently plays as\r
  93 > > both user and computer readable.\r
  94 > > \r
  95 > > I've also got the code to do everything using document ID's instead of\r
  96 > > message ID's.  As a side-effect, it makes the search output clean and\r
  97 > > readily parsable since document ID's are just numbers.  Hence, there\r
  98 > > are no quoting or escaping issues (plus the output is much more\r
  99 > > compact).  I haven't sent this to the list yet because I haven't had a\r
 100 > > chance to benchmark it and determine if the performance benefits make\r
 101 > > exposing document ID's worthwhile.\r
 102 > \r
 103 > Jamie Zawinski once said/wrote [1]:\r
 104 >   'Some people, when confronted with a problem, think "I know,\r
 105 >   I'll use regular expressions." Now they have two problems.'\r
 106 > \r
 107 > With this in mind, I set out to get rid of this whole regex mess altogether,\r
 108 > by populating the search buffer using Notmuch's JSON output instead of doing\r
 109 > brittle text matching tricks.\r
 110 > \r
 111 > Looking for some documentation, I stumbled upon a long-forgotten gem [2].\r
 112 > \r
 113 > David's already done pretty much all of the work for us!\r
 114 \r
 115 Yes, similar thoughts were running through my head as I futzed with\r
 116 the formatting for this.  My concern with moving to JSON for search\r
 117 buffers is that parsing it is about *30 times slower* than the current\r
 118 regexp-based approach (0.6 seconds versus 0.02 seconds for a mere 1413\r
 119 result search buffer).  I think JSON makes a lot of sense for show\r
 120 buffers because there's generally less data and it has a lot of\r
 121 complicated structure.  Search results, on the other hand, have a very\r
 122 simple, regular, and constrained structure, so JSON doesn't buy us\r
 123 nearly as much.\r
 124 \r
 125 JSON is hard to parse because, like the text search output, it's\r
 126 designed for human consumption (of course, unlike the text search\r
 127 output, it's also designed for computer consumption).  There's\r
 128 something to be said for the debuggability and generality of this and\r
 129 JSON is very good for exchanging small objects, but it's a remarkably\r
 130 inefficient way to exchange large amounts of data between two\r
 131 programs.\r
 132 \r
 133 I guess what I'm getting at, though it pains me to say it, is perhaps\r
 134 search needs a fast, computer-readable interchange format.  The\r
 135 structure of the data is so simple and constrained that this could be\r
 136 altogether trivial.\r
 137 \r
 138 Or maybe I need a faster computer.\r
 139 \r
 140 \r
 141 If anyone is curious, here's how I timed the parsing.\r
 142 \r
 143 (defmacro time-it (code)\r
 144   `(let ((start-time (get-internal-run-time)))\r
 145      ,code\r
 146      (float-time (time-subtract (get-internal-run-time) start-time))))\r
 147 \r
 148 (with-current-buffer "json"\r
 149   (goto-char (point-min))\r
 150   (time-it (json-read)))\r
 151 \r
 152 (with-current-buffer "text"\r
 153   (goto-char (point-min))\r
 154   (time-it\r
 155    (while (re-search-forward "^\\(thread:[0-9A-Fa-f]*\\) \\([^][]*\\) \\(\\[[0-9/]*\\]\\) \\([^;]*\\); \\(.*\\) (\\([^()]*\\))$" nil t))))\r