From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Literate Programming - Continue a Source Block? Date: Wed, 15 Jun 2011 10:23:44 -0700 Message-ID: <877h8nuhr3.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> <87oc25mqqq.fsf@Rainer.invalid> <8739jhv4ma.fsf@gmail.com> <87mxhn8n7i.fsf@Rainer.invalid> <87tybtidzy.fsf@gmail.com> <87ei2wgmvw.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:41773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWtsu-0000Zp-Fr for emacs-orgmode@gnu.org; Wed, 15 Jun 2011 13:28:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWtss-0002Ny-3R for emacs-orgmode@gnu.org; Wed, 15 Jun 2011 13:28:08 -0400 Received: from mail-iw0-f169.google.com ([209.85.214.169]:62826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWtsr-0002NW-NJ for emacs-orgmode@gnu.org; Wed, 15 Jun 2011 13:28:05 -0400 Received: by iwg8 with SMTP id 8so636230iwg.0 for ; Wed, 15 Jun 2011 10:28:04 -0700 (PDT) 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: Achim Gratz Cc: emacs-orgmode@gnu.org Rather than feeling our way forward step by step it seems that simply following the behavior of noweb would both 1. allow for easy transition between noweb and babel 2. benefit from the years of experience and design accumulated in the noweb project Does anyone on this list know the noweb system well enough to specify its behavior in this regard, and to describe what functional changes would be required to bring Babel into line with noweb behavior? Thanks -- Eric Achim Gratz writes: > Eric Schulte writes: >> Thanks for sharing your thoughts. How would you feel about moving away >> from special source block names and moving towards implementing this >> behavior with a header argument? > > I'm not feeling strongly either way... I'm wanting to use Babel for some > stuff at work, but haven't got around to learn it well enough to set > things in motion. So my current investment is still small. :-) > >> Specifically two header arguments >> which would both take the name of a named code block, these header >> arguments would be as follows >> >> - append :: will append the current code block's body to the named code >> block during tangling >> >> - overwrite :: will overwrite the named code block's body with the body >> of the current code block >> >> for simple concatenate the value of the append header argument could be >> easily set on the file or subtree level. > > This looks good, but it sort of turns the tables (I hope I get this > right, it was a longer day than I hoped). With noweb references, you > need to resolve the name of the source block at the target. With the > header arguments you propose you need to resolve the target block name > at the source. Both ways are useful, but it seems that it would be > difficult to track all targets from a single source even if supposedly > one could have a list of targets (that would only be useful for > "overwrite" unless you are really lucky). This asymmetry is > inescapeable when you try to use source blocks like "include files". > Another problem arises when you need to (again) reorder source blocks at > the target. You can't do that from the source, since not only would the > source then need to know all targets, it would also need to know all > other sources and their ordering in all targets. > >> I feel that for many reasons (most of which have been discussed in >> relation to a header argument solution earlier in this thread) such a >> solution would be simpler and more consistent with the rest of Babel >> than the current name-based solution. > > I'd think if there was an API to get at the contents of the header > arguments (perhaps using or modeled after the properties API), both the > forward and backward resolution could use the same internal mechanism > and noweb references could be changed (or extended) to (optionally) use > a match with some header argument (e.g. :id or :srcname). So let's say > that'd then allow: > > <<:id "bla">> > > to build a list of all source blocks with that header argument and > tangle them in list order. And since noweb references now really expect > a list, you can just as well feed them a custom function that cobbles > that list from multiple header arguments or properties. > > Thinking along those lines I'm beginning to wonder if not the whole > header should be put into a drawer (I've often wished this was the case > for #+TBLFM). > > > > Regards, > Achim. -- Eric Schulte http://cs.unm.edu/~eschulte/