From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Literate Programming - Continue a Source Block? Date: Thu, 16 Jun 2011 21:39:53 -0700 Message-ID: <87hb7pxe92.fsf@gmail.com> References: <87pqmokh6d.fsf@fester.com> <80k4cw22uf.fsf@somewhere.org> <87fwnkjqoh.fsf@fester.com> <87mxhsnmcf.fsf@gmail.com> <877h8wj9za.fsf@fester.com> <877h8tv6yh.fsf@gmail.com> <87fwnhgps2.fsf@fester.com> <871uz0m8q9.fsf@gmail.com> <87oc238vby.fsf@fester.com> <87zkllie03.fsf@gmail.com> <871uyv7jxm.fsf@fester.com> <871uyvuhqy.fsf@gmail.com> <87wrgm6g3a.fsf@fester.com> <87hb7qcr3z.fsf@gmail.com> <878vt15bc8.fsf@fester.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:45800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXQqf-0002W8-Am for emacs-orgmode@gnu.org; Fri, 17 Jun 2011 00:40:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXQqd-0007rM-RI for emacs-orgmode@gnu.org; Fri, 17 Jun 2011 00:40:01 -0400 Received: from mail-iy0-f169.google.com ([209.85.210.169]:44850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXQqd-0007rH-Jc for emacs-orgmode@gnu.org; Fri, 17 Jun 2011 00:39:59 -0400 Received: by iyl8 with SMTP id 8so2273262iyl.0 for ; Thu, 16 Jun 2011 21:39:59 -0700 (PDT) In-Reply-To: <878vt15bc8.fsf@fester.com> (Neeum Zawan's message of "Thu, 16 Jun 2011 21:30:15 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Neeum Zawan Cc: emacs-orgmode@gnu.org Neeum Zawan writes: > Eric Schulte writes: > >> How about the following solution, which is based on a new :noweb-ref >> header argument. >> >> When expanding ``noweb'' style references the bodies of all code block >> with /either/ a block name matching the reference name /or/ a :noweb-ref >> header argument matching the reference name will be concatenated >> together to form the replacement text. >> >> By setting this header argument at the sub-tree or file level, simple >> code block concatenation may be achieved. For example, when tangling >> the following Org-mode file, the bodies of code blocks will be >> concatenated into the resulting pure code file. > > Hi, > > Your example is not completely clear. I noticed you didn't put any names > for the source blocks that use the noweb-ref. Is it necessary not to > name them, The source code blocks may have names, as before all code block names should be unique or the behavior may be undefined. > or can one name them but their names will still have to be unique and > are orthogonal to concatenation (i.e. they have names, but the > concatenation is due to whatever the argument of noweb-ref is)? > The value of the :noweb-ref header argument supersedes the name of the code block for noweb expansion. To preserve existing semantics and to avoid requiring the use of the :noweb-ref header argument in simple cases, the code block name will be used to resolve noweb references in blocks which do not have a :noweb-ref header argument. > > I think either way, this solution serves my purpose. My original > suggestion was to have a header whose value would be "append" to allow > for concatenation if the name matches a previous source block. It seems > your solution above is the same except instead of looking at the name of > the source block, it looks at the argument of noweb-ref. > Yup, happy this sounds like it should work for your original need. > > Overwriting is still not supported, but I don't know if that's all that > important (I don't have an immediate need for it). And noweb by default > did not have it either, so perhaps it's not needed for most tasks This was my thinking. > (OTOH, you may want to think about what the best solution is if later > on you decide to add overwriting capability). > If someone finds a real need for overwriting code blocks, hopefully the specifics of their need will point towards an implementation. > > Thanks. Hope to see this or something like it soon. > You welcome, hope this turns out to be helpful -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/