Date: Thu, 12 Jul 2012 20:10:37 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: craven@gmx.net
Subject: Re: [PATCH v4 3/3] Use the structured format printer for JSON in
	notmuch search.
Message-ID: <20120713001037.GL7332@mit.edu>
References: <87d34hsdx8.fsf@awakening.csail.mit.edu>
	<1342079004-5300-1-git-send-email-craven@gmx.net>
	<1342079004-5300-4-git-send-email-craven@gmx.net>
	<20120713000234.GK7332@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20120713000234.GK7332@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

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.