Re: [PATCH 2/2] notmuch.el:notmuch-search-process-filter: Rewritten. Cope with incomp...

diff --git a/4b/2be5b4537bf1d0751f311060509ab0f7525e7f b/4b/2be5b4537bf1d0751f311060509ab0f7525e7f
new file mode 100644 (file)
index 0000000..8205fcc
--- /dev/null
+++ b/4b/2be5b4537bf1d0751f311060509ab0f7525e7f
@@ -0,0 +1,117 @@
+Return-Path: <cworth@cworth.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id E90D6429E20\r
+       for <notmuch@notmuchmail.org>; Thu, 10 Mar 2011 18:09:52 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.99\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5\r
+       tests=[ALL_TRUSTED=-1, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id S1BJqQ-rj18y; Thu, 10 Mar 2011 18:09:52 -0800 (PST)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 4E490431FB5;\r
+       Thu, 10 Mar 2011 18:09:52 -0800 (PST)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id DED5454C0C4; Thu, 10 Mar 2011 18:09:51 -0800 (PST)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Austin Clements <amdragon@mit.edu>, Thomas Schwinge <thomas@schwinge.name>\r
+Subject: Re: [PATCH 2/2] notmuch.el:notmuch-search-process-filter: Rewritten.\r
+       Cope with incomplete lines.\r
+In-Reply-To: <AANLkTi=_ZqOao8mMRRb=gLmX+MWchqZ0Af-VxJquwure@mail.gmail.com>\r
+References: <87zkqeiffj.fsf@kepler.schwinge.homeip.net>\r
+       <1296690999-16542-3-git-send-email-thomas@schwinge.name>\r
+       <AANLkTi=_ZqOao8mMRRb=gLmX+MWchqZ0Af-VxJquwure@mail.gmail.com>\r
+User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1\r
+       (i486-pc-linux-gnu)\r
+Date: Thu, 10 Mar 2011 18:09:51 -0800\r
+Message-ID: <87oc5i8l1s.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Fri, 11 Mar 2011 02:09:53 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Thu, 3 Feb 2011 12:06:20 -0500, Austin Clements <amdragon@mit.edu> wrote:\r
+> Nice catch.\r
+>=20\r
+> Is there a reason you keep the remaining data in a string instead of\r
+> taking the more idiomatic elisp approach of leaving it in the process\r
+> buffer?\r
+\r
+Thomas is excused since he was just modifying my code originally.\r
+\r
+And now I've gone and made it even worse by adding a bunch of hideously\r
+non-idiomatic expressions like:\r
+\r
+       (while (and (< line (length string)) (=3D (elt string line) ?\n))\r
+         (setq line (1+ line)))\r
+\r
+The rough equivalent in C would be quite natural (where we actually have\r
+pointers):\r
+\r
+       while (*s && *s =3D=3D '\n')\r
+            s++;\r
+\r
+but the above elisp is quite nasty.\r
+\r
+> In fact, the code would probably be simpler if you\r
+> immediately appended the string to the process buffer like a normal\r
+> process-filter and then peeled things away using buffer-oriented\r
+> regexp functions like looking-at.  Elisp is a lot better at\r
+> manipulating buffers than it is at manipulating strings.\r
+\r
+I spent a bit of time trying this. Using looking-at is definitely better\r
+than string-match since we can then use things like (match-string 1)\r
+rather than (match-string 1 string). And getting rid of the "line"\r
+variable means that all of the ugly expressions like the one I showed\r
+above went away.\r
+\r
+The approach I tried was to use a temporary buffer for the unparsed data\r
+and the process buffer for the resulting parsed data. The code got a bit\r
+awkward as I kept having to jump back and for between (with-temp-buffer)\r
+and (with-current-buffer buffer)---particularly due to the buffer-local\r
+variable to hold the trailing data from the past run.\r
+\r
+A better approach might be to use a single buffer, leave the unparse\r
+data at the end, and just make it hidden.\r
+\r
+But I'll leave this alone for now since fighting elisp has left me\r
+annoyed. If anyone wants to clean up my hideous elisp here, then that\r
+would be fine with me.\r
+\r
+=2DCarl\r
+\r
+=2D-=20\r
+carl.d.worth@intel.com\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iD8DBQFNeYRv6JDdNq8qSWgRAo6rAJkBq1/ECsairoUAV9ZiKzCzZbF25ACfTdaD\r
+yuEIt9J/DdmcbfAVQJjVe0k=\r
+=K5J8\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r