From 9e5d746fada1e859fba1903e4bfc7d842008b30b Mon Sep 17 00:00:00 2001 From: Adam Wolfe Gordon Date: Mon, 30 Apr 2012 12:17:10 +1800 Subject: [PATCH] Re: [RFC] Use JSON in emacs interface --- 94/1987726d690ba4bf33d5c094f6467c4ec1ad23 | 111 ++++++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 94/1987726d690ba4bf33d5c094f6467c4ec1ad23 diff --git a/94/1987726d690ba4bf33d5c094f6467c4ec1ad23 b/94/1987726d690ba4bf33d5c094f6467c4ec1ad23 new file mode 100644 index 000000000..12359eac0 --- /dev/null +++ b/94/1987726d690ba4bf33d5c094f6467c4ec1ad23 @@ -0,0 +1,111 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id C3F6F431FAF + for ; Sun, 29 Apr 2012 11:17:13 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id s6PIxd1mgfwi for ; + Sun, 29 Apr 2012 11:17:12 -0700 (PDT) +Received: from mail-lpp01m010-f53.google.com (mail-lpp01m010-f53.google.com + [209.85.215.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 1EE49431FAE + for ; Sun, 29 Apr 2012 11:17:11 -0700 (PDT) +Received: by lahc1 with SMTP id c1so1684002lah.26 + for ; Sun, 29 Apr 2012 11:17:10 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=google.com; s=20120113; + h=mime-version:sender:x-originating-ip:in-reply-to:references:date + :x-google-sender-auth:message-id:subject:from:to:cc:content-type + :content-transfer-encoding:x-gm-message-state; + bh=zxfDkEFlIHbWBZqIwe2bdZhD/FrXQnv9I+qsdDZuZ84=; + b=NpdfGZg5RI+5jviP+ypsxfsPohDbqXM5+JHzQrL/oye+8+fU5VA1WNb1Zveb/JG0Au + K4hBBK18LIJSMoOhlDj7hSynmGHm3qkrh8BwwERRmS3iaPSBaigFz6lT6hgn8SrLQX/h + +9us5F5Q1iKB5XRGZLQnDzcfj9HAgB51aHHWJ0Q43+lf9fHNMGFNddliUo1rdCcgz4hx + /ay+b1reK70F0iWLxTehSbZPIjo27JbDiyTpsAhTmEoBWDFOjyYDbKoP1CYXiT7kePDk + GvzwTfKAJMJ+BKI282zcsJHLaOxeyRVrUJeT47jt7zHVA473zmb/qN232+ihOo0pkh1n + ZZJQ== +MIME-Version: 1.0 +Received: by 10.152.133.144 with SMTP id pc16mr17806389lab.0.1335723430378; + Sun, 29 Apr 2012 11:17:10 -0700 (PDT) +Sender: awg@xvx.ca +Received: by 10.112.82.163 with HTTP; Sun, 29 Apr 2012 11:17:10 -0700 (PDT) +X-Originating-IP: [96.52.216.56] +In-Reply-To: <87ty02v786.fsf@gmail.com> +References: <87ty02v786.fsf@gmail.com> +Date: Sun, 29 Apr 2012 12:17:10 -0600 +X-Google-Sender-Auth: P_5N9wbhFNW71vRouzaFOPZoyYo +Message-ID: + +Subject: Re: [RFC] Use JSON in emacs interface +From: Adam Wolfe Gordon +To: Chris Gray +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable +X-Gm-Message-State: + ALoCoQmd/IywbraIrlPVAFmbiKWdoMPKN57qryulsThNRE+DOjImY9d1T+87vwh5NTJn5QR1ezWC +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sun, 29 Apr 2012 18:17:13 -0000 + +Hi Chris, + +On Sun, Apr 29, 2012 at 10:22, Chris Gray wrote: +> I first thought of changing the regex so that it looked for the last +> semicolon in the string or something like that, but that would just move +> the problem. =A0(Semicolons are probably more frequent in subject lines +> than in author names.) =A0So it seems to me that what is needed is for +> notmuch and emacs to talk with each other in a format that is +> unambiguously parseable. =A0Since notmuch search already has the option o= +f +> outputting to JSON, that seems like a natural fit. +> +> Emacs has an existing JSON parser, +> , +> but it doesn't appear that it is able to parse progressively, meaning +> that it wouldn't be able to display results as they come in from notmuch +> search if used as-is. =A0My guess is that its parts could be hacked +> together to overcome this limitation though. +> +> Anyway, if others think this is a good idea, I'm willing to do the +> coding. + +I think this is a great idea. If you look at notmuch-mua.el and +notmuch-query.el, you'll see that we already use json.el for reply and +parts of show. + +As for parsing progressively to show search results as they arrive, +I'd be inclined to instead implement paging, so emacs could ask for +just the first n results, display them, then ask for the next n +results, etc. Or maybe ask for the results grouped, so that there +would be a valid JSON object for the first n results, then another for +the next n, etc. This might be a tricky thing to design and implement, +but I think it's been discussed before as something that would be nice +to have. + +Personally, I think it would be fine to implement the JSON search +first, then deal with progressive parsing and/or grouping, but others +may differ here. Either way, I'd be happy to review patches for this +and offer any suggestions. + +-- Adam -- 2.26.2