From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Literate Programming - Continue a Source Block? Date: Mon, 13 Jun 2011 15:04:32 -0700 Message-ID: <87tybtidzy.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:43116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWFGD-0001FM-VG for emacs-orgmode@gnu.org; Mon, 13 Jun 2011 18:05:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWFGC-0007gw-8b for emacs-orgmode@gnu.org; Mon, 13 Jun 2011 18:05:29 -0400 Received: from mail-pw0-f41.google.com ([209.85.160.41]:38770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWFGB-0007gr-QZ for emacs-orgmode@gnu.org; Mon, 13 Jun 2011 18:05:28 -0400 Received: by pwi12 with SMTP id 12so2788670pwi.0 for ; Mon, 13 Jun 2011 15:05:26 -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 Achim Gratz writes: > Eric Schulte writes: >> I think "append" is just as clear as concatenate, > > Fair enough, in my mind "append" needs an existing entity, but I guess > it could be an empty one. > >> and collate implies shuffling which is not happening. > > Well, I was getting ahead of myself... I hope you don't mind me harping > on about this. > >> I'm wary of adding too much duplicate functionality. It is already >> possible to organize the tangling of many named code blocks using noweb >> reference expansion (a feature which I've used myself on real projects >> in the past). This existing method allows for unique block names and >> for arbitrary tangling order. > > The examples presented in this thread pointed out one difficulty with > how noweb references currently work, namely that you need to know in > advance all block names for finally tangling them and that when adding > or removing things you need to remember to keep these references current > in potentially many places. > >> Simplicity is the only reason that the new name-based appending behavior >> was implemented, simplicity which (in my opinion) is lost when the user >> defines a naming and sorting schema. > > My general objection is that since you now require that the names be all > the same, there is no way to distinguish between those blocks anymore. > This will come back to bite you when you then later need to make a > distinction since you'll then have to rework everything to unique names > again. I consider that sort of simplicity a trap for the unwary. > > Splitting between a basename and an index extension would instead allow > for appending with the basename and still getting at individual blocks > using the full name (with the index part). I've had one specific > use-case in mind where this would be needed. You'd normally just > concatenate all source blocks (let's assume for the moment that the > index part is separated from the basename by "::") > > <> > > Let's say you have three source blocks and need to point-patch the > second one for this run: > > <> > <> > <> > > If the three source blocks are all just named "source", there's no way > to do this short of changing their names and all the references that use > them. > > The index part doesn't have to be numeric, it just needs to be > orderable. Anyone not using index extensions gets an implicit one by > order of appearance, so that wouldn't require any code duplication and > you can in this case still say > > <> > > Being able to provide custom naming and sorting schemes could be > deferred to hook functions the user has to provide, as they will indeed > be rarely needed. So an implementation that keeps current behaviour > would provide an implicit indexer (by order of appearance), an empty > sorter and three selectors (all=append, first last). Anyone who needs > more than that has to customize those functions, but I suppose the more > common application scenarios will sneak into the baseline sooner or > later. The move from implicit to explicit indexing should be supported > by providing another hook in the implicit indexer. > > > Regards, > Achim. Hi Achim, 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? 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. 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. Thoughts? -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/