unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Adam Wolfe Gordon <awg+notmuch@xvx.ca>
To: Chris Gray <chrismgray@gmail.com>
Cc: notmuch@notmuchmail.org
Subject: Re: [RFC] Use JSON in emacs interface
Date: Sun, 29 Apr 2012 12:17:10 -0600	[thread overview]
Message-ID: <CAMoJFUtY-Dzv8N6gs+8B6c43APqz9J9OSE05eDWLq_tUMEoW3A@mail.gmail.com> (raw)
In-Reply-To: <87ty02v786.fsf@gmail.com>

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.  (Semicolons are probably more frequent in subject lines
> than in author names.)  So 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.  Since notmuch search already has the option of
> 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=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.  My 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

  reply	other threads:[~2012-04-29 18:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-29 16:22 [RFC] Use JSON in emacs interface Chris Gray
2012-04-29 18:17 ` Adam Wolfe Gordon [this message]
2012-04-29 20:11 ` Austin Clements

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMoJFUtY-Dzv8N6gs+8B6c43APqz9J9OSE05eDWLq_tUMEoW3A@mail.gmail.com \
    --to=awg+notmuch@xvx.ca \
    --cc=chrismgray@gmail.com \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).