Quoth Mark Walters on Dec 01 at 12:24 pm: > > On Sat, 01 Dec 2012, Tomi Ollila <tomi.ollila@iki.fi> wrote: > > On Sat, Dec 01 2012, Mark Walters wrote: > > > >> Hi > >> > >> Overall I like the series: I think I agree with all of Jani's > >> comments. > >> > >> My one extra comment is that I think we should decide on whether we also > >> want a sexp plist version. I think we might want one for the emacs > >> front-end as that currently uses plists for everything. > >> > >> If we do we might want to change the names a little, both for functions > >> and options (eg sexp_a and sexp_p or something). Probably a lot of > >> sprinter-sexp would be common to both versions. > > > > This is an important question that needs to be addressed fast: options > > are: > > > > 1) have options to spit both alist & plist formats > > 2) when converting emacs to use s-expressions, convert it to use alists > > 3) start using plists instead of alists in Peter's android client > > Ok I have looked at this and the changes needed to output plist (or > both) are pretty small: the only functions from sprinter-sexp.c that > need to be changed are sexp_end and sexp_map_key. The total diff from > alist to plist is about 10 lines. I have a version which allows both > (the same sprinter file creates both possibilities) and have hooked it > into emacs/notmuch-show.el and it all seems to work. > > (Search is more difficult as that uses the async parser; indeed even for > show I used sexp-at-point as suggested by Tomi which seems rather > underdocumented but does seem to work) I'm happy to write an async sexp parser. I specifically designed the async JSON parser with later switching to sexps in mind, so I already have a plan for how to do this.