MIME-Version: 1.0
Sender: awg@xvx.ca
In-Reply-To: <87ty02v786.fsf@gmail.com>
References: <87ty02v786.fsf@gmail.com>
Date: Sun, 29 Apr 2012 12:17:10 -0600
Message-ID:
 <CAMoJFUtY-Dzv8N6gs+8B6c43APqz9J9OSE05eDWLq_tUMEoW3A@mail.gmail.com>
Subject: Re: [RFC] Use JSON in emacs interface
From: Adam Wolfe Gordon <awg+notmuch@xvx.ca>
To: Chris Gray <chrismgray@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

Hi Chris,

On Sun, Apr 29, 2012 at 10:22, Chris Gray <chrismgray@gmail.com> 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,
> <http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/lisp/json.el?root=3D=
emacs>,
> 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