Re: The overloading of show (was Re: [PATCH] Output unmodified Content-Type header...
authorDavid Edmondson <dme@dme.org>
Mon, 16 Jan 2012 13:50:43 +0000 (13:50 +0000)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:42:16 +0000 (09:42 -0800)
bc/6aebfa969e1e26359bf08d9a1b3c80e2e14b9a [new file with mode: 0644]

diff --git a/bc/6aebfa969e1e26359bf08d9a1b3c80e2e14b9a b/bc/6aebfa969e1e26359bf08d9a1b3c80e2e14b9a
new file mode 100644 (file)
index 0000000..072c865
--- /dev/null
@@ -0,0 +1,132 @@
+Return-Path: <dme@dme.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 981FE431FC9\r
+       for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:50:54 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 kbDLWPQihOLC for <notmuch@notmuchmail.org>;\r
+       Mon, 16 Jan 2012 05:50:53 -0800 (PST)\r
+Received: from mail-ww0-f45.google.com (mail-ww0-f45.google.com\r
+ [74.125.82.45])       (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
+ certificate requested)        by olra.theworths.org (Postfix) with ESMTPS id\r
+ 4D729431FAE   for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:50:53 -0800\r
+ (PST)\r
+Received: by wgbdr13 with SMTP id dr13so220981wgb.2\r
+       for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:50:52 -0800 (PST)\r
+Received: by 10.180.102.169 with SMTP id fp9mr20022551wib.9.1326721851567;\r
+       Mon, 16 Jan 2012 05:50:51 -0800 (PST)\r
+Received: from hotblack-desiato.hh.sledj.net\r
+       (host81-149-164-25.in-addr.btopenworld.com. [81.149.164.25])\r
+       by mx.google.com with ESMTPS id ev11sm6851363wbb.2.2012.01.16.05.50.49\r
+       (version=TLSv1/SSLv3 cipher=OTHER);\r
+       Mon, 16 Jan 2012 05:50:50 -0800 (PST)\r
+Received: by hotblack-desiato.hh.sledj.net (Postfix, from userid 30000)\r
+       id EC944A0397; Mon, 16 Jan 2012 13:50:46 +0000 (GMT)\r
+To: Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: The overloading of show (was Re: [PATCH] Output unmodified\r
+       Content-Type header value for JSON format.)\r
+In-Reply-To: <20120115003617.GH1801@mit.edu>\r
+References: <20120115003617.GH1801@mit.edu>\r
+User-Agent: Notmuch/0.11+64~g42e8f66 (http://notmuchmail.org) Emacs/24.0.92.1\r
+       (x86_64-pc-linux-gnu)\r
+From: David Edmondson <dme@dme.org>\r
+Date: Mon, 16 Jan 2012 13:50:43 +0000\r
+Message-ID: <cunaa5nu570.fsf@hotblack-desiato.hh.sledj.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+Cc: notmuch <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: Mon, 16 Jan 2012 13:50:54 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Sat, 14 Jan 2012 19:36:17 -0500, Austin Clements <amdragon@MIT.EDU> wrot=\r
+e:\r
+> ...there are several levels of structure here:\r
+>=20\r
+> 1. Threads (query results)\r
+> 2. Thread structure\r
+> 3. Message structure (MIME)\r
+> 4. Part content\r
+>=20\r
+> Currently, search returns 1; show --format=3Djson returns 2, 3, and\r
+> sometimes 4 (but sometimes not); and show --format=3Draw returns 4.\r
+> Notably, 1 does not require opening message files (neither does 2),\r
+> which I consider an important distinction between search and show.\r
+>=20\r
+> Some of the discussion has been about putting 4 squarely in the realm\r
+> of show --format=3Draw.  One counterargument (which has grown on me\r
+> since this discussion) is that the part content included in\r
+> --format=3Djson can be thought of as pre-fetching content that clients\r
+> are likely to need in order to avoid re-parsing the message in most\r
+> circumstances.  I believe this is not the *intent* of the current\r
+> code, though without a specification of the JSON format it's hard to\r
+> tell.\r
+\r
+The JSON output included what was considered useful (mostly for the\r
+Emacs UI), but how much deep thought went into 'useful' I couldn't say.\r
+\r
+> Other discussion (more interesting, in my mind) has been about\r
+> separating retrieving thread structure, 2, from retrieving message\r
+> structure, 3.  To me, splitting these feels much more natural than\r
+> what we do now, which seems to be inflexibly bound to the specific way\r
+> the Emacs show mode currently works.  The thread structure is readily\r
+> available from the database, so I think separating these would open up\r
+> some new UI opportunities, particularly easy and fast thread outlining\r
+> and navigation.\r
+\r
+Given that the current output already includes both 2 and 3, anything\r
+that could be done with 2 can be done with the current output, so\r
+there's no block on the kind of innovation that you describe other than\r
+possibly some performance problems.\r
+\r
+notmuch-lkml.el[1] was a quick prototype of an alternative way to find\r
+messages to read based on suggestions from Aneesh. It could have used\r
+the proposed 'thread structure only' output.\r
+\r
+The changes you allude to make sense. My only concern would be any\r
+potential impact on the current Emacs UI's use of JSON output. Switching\r
+to a model where a typical 'notmuch-show' buffer requires many calls to\r
+notmuch (and commensurate JSON parsing) may perform significantly worse\r
+than the current approach.\r
+\r
+> I believe it would also simplify the code and address some irritating\r
+> asymmetries in the way notmuch show handles the --part argument.\r
+\r
+Footnotes:=20\r
+[1]  http://dme.org/data/emacs/notmuch-lkml.el\r
+\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iEYEARECAAYFAk8UKzMACgkQaezQq/BJZRbBxACcCg61tuL9eLvxrXrIiWL3OVTb\r
+JP8AnibEvGhy4wRtAZyEZHvaNHgYSJDJ\r
+=GQP7\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r