From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id CF91D429E40 for ; Sat, 21 Jan 2012 15:17:23 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_MIME_NO_TEXT=0.01] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf5Y3fd1NK1p for ; Sat, 21 Jan 2012 15:17:23 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by olra.theworths.org (Postfix) with SMTP id E68C4431FAF for ; Sat, 21 Jan 2012 15:17:22 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2012 23:17:21 -0000 Received: from www.nexoid.at (EHLO mail.nexoid.at) [178.79.130.240] by mail.gmx.net (mp064) with SMTP; 22 Jan 2012 00:17:21 +0100 X-Authenticated: #201305 X-Provags-ID: V01U2FsdGVkX1/Ny8JSFHLNB8Kh2mgdIhqlRWfsU29ZzxYORz702e n55soaVb5eVX+q Received: by mail.nexoid.at (Postfix, from userid 1000) id 1270C57019; Sun, 22 Jan 2012 00:17:21 +0100 (CET) From: "Peter Feigl" To: Austin Clements Subject: Re: [PATCH] rewriting notmuch-search for structured output to make other output formats easier In-Reply-To: <20120121220407.GK16740@mit.edu> References: <1327180568-30385-1-git-send-email-craven@gmx.net> <20120121220407.GK16740@mit.edu> User-Agent: Notmuch/0.11+77~gad6d0d5 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu) Date: Sun, 22 Jan 2012 00:17:17 +0100 Message-ID: <87obtwlk76.fsf@nexoid.at> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Y-GMX-Trusted: 0 Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 23:17:24 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Sat, 21 Jan 2012 17:04:07 -0500, Austin Clements wrot= e: > Quoth Peter Feigl on Jan 21 at 10:16 pm: > I think this is a great idea and I'm a fan of having an S-expression > format, but I also think there's a much easier and more general way to > structure this. >=20 > In particular, I don't think you should hijack search_format, since > you'll wind up repeating most of this work for anything else that > needs to output structured data (notmuch show, at least). Rather, I'd > suggest creating a general "structure printer" struct that isn't tied > to search. You've essentially already done this, you just called it > search_format. Then, leave the existing format callbacks in place, > just use this new API instead of lots of printf calls. I'm sorry I haven't been more clear about this, the intention was all along to check whether this would be ok in notmuch-search, and if it got accepted there, to factor it out into a separate file and then use it in notmuch-show and notmuch-reply. There's nothing in the printer (except for the name of the struct) that ties it to search. > What about all of those annoying {tag,item}_{start,sep,end} fields? I > think you can simultaneously get rid of those *and* simplify the > structure printer API. If the structure printer is allowed to keep a > little state, it can automatically insert separators. With a little > nesting state, it could even insert terminators by just saying "pop me > to this level". This could probably be better, but I'm imagining > something like I agree, however this is complicated by the fact that there are additional restrictions on the actually printed code: newlines should be placed at strategic locations to improve parsability, which could be hard to decide in the printer alone without support from the logic that drives it. > struct sprinter * > new_json_sprinter (const void *ctx, FILE *stream); > struct sprinter * > new_sexp_sprinter (const void *ctx, FILE *stream); >=20 > /* Start a map (a JSON object or a S-expression alist/plist/whatever) > * and return the nesting level of the map. */ > int > sprinter_map (struct sprinter *sp); > /* Start a list (aka array) and return the nesting level of the list. */ > int > sprinter_list (struct sprinter *sp); >=20 > /* Close maps and lists until reaching level. */ > void > sprinter_pop (struct sprinter *sp, int level); >=20 > void > sprinter_map_key (struct sprinter *sp, const char *key); > void > sprinter_number (struct sprinter *sp, int val); > void > sprinter_string (struct sprinter *sp, const char *val); > void > sprinter_bool (struct sprinter *sp, notmuch_bool_t val); >=20 > and that's it. This would also subsume your format_attribute_* > helpers. >=20 > Unfortunately, it's a pain to pass things like a structure printer > object around formatters (too bad notmuch isn't written in C++, eh?). > I think it's better to address this than to structure around it. > Probably the simplest thing to do is to make a struct for formatter > state and pass that in to the callbacks. You could also more > completely emulate classes, but that would probably be overkill for > this. I believe this approach is similar to the one I've implemented (though probably higher level, not so many details explicitly written into the formatting code). I would suggest trying to get any sort of structured formatters (whether more like your suggestions or like the thing I implemented doesn't matter so much) into the main codebase, and then refactoring the other parts to use it. I've thought about providing a single patch to all of notmuch that accomplishes this, but I've deemed it too large and complicated to be accepted, I thought limiting it to notmuch-search would be a way to get it set up, so that it could be expanded to the other parts later. Thanks for the comments, I'll keep thinking about your design, a very interesting idea! Peter --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: This is a digital signature. For details, see http://www.gnupg.org. iEYEARECAAYFAk8bR30ACgkQKbx0MfH7UNw0sACcDipsvQvLXfaQWxbnZgXEj+8N haAAn1VLUZKi0r6m6IiC1NwBJ7hohWO7 =iPde -----END PGP SIGNATURE----- --=-=-=--