[PATCH v4 3/3] Use the structured format printer for JSON in notmuch search.

[Austin Clements]

Quoth myself on Jul 12 at  8:02 pm:
> This is fantastic.  It simplifies the code a lot, and I think it opens
> up opportunities to simplify it even further.
> 
> Detailed comments are below, but first one general comment.  For the
> text format, I wonder if most of the special case code would go away
> with a stub sprinter that did nothing for most operations and for
> string printed the string followed by a newline (or maybe the newline
> would be printed by the "frame" method or whatever you end up calling
> it).  I believe this would unify all of the code in do_search_tags and
> do_search_files between the two formats.  For do_search_threads,
> you'll still need some special-casing to format the summary line, but
> I think it would unify all of the framing code.  (If this does work
> out, some of my comments below will be irrelevant.)

Oh, wait, the text format adds prefixes...

I think something along the lines of what I described above would
still simplify things.  I can think of two ways to do it.  You could
have a completely stub sprinter where everything is a no-op; that
would at least save the predication of calls like
format->begin_list ().  Or, you could have an additional function for
the text formatter that registers a prefix, and have the string method
first print that prefix and then the argument string.  This additional
function doesn't have to be a method of sprinter; it could just be a
regular function that stashes the prefix away somewhere (a global
variable's probably fine; if you want to be fancy you store it in an
sprinter_text extension of sprinter_t like the one JSON uses).  For
the JSON format, this would be a no-op, so you could call it
regardless of what format you've selected.