From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neeum Zawan Subject: Re: Literate Programming - Continue a Source Block? Date: Fri, 10 Jun 2011 17:44:45 -0700 Message-ID: <87fwnhgps2.fsf@fester.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([140.186.70.92]:54201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVCHj-0005UX-Va for emacs-orgmode@gnu.org; Fri, 10 Jun 2011 20:42:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QVCHh-0006Um-ST for emacs-orgmode@gnu.org; Fri, 10 Jun 2011 20:42:43 -0400 Received: from lo.gmane.org ([80.91.229.12]:60560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVCHh-0006UN-A9 for emacs-orgmode@gnu.org; Fri, 10 Jun 2011 20:42:41 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QVCHf-0003T0-0l for emacs-orgmode@gnu.org; Sat, 11 Jun 2011 02:42:39 +0200 Received: from c-71-237-233-41.hsd1.or.comcast.net ([71.237.233.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Jun 2011 02:42:39 +0200 Received: from mailinglists by c-71-237-233-41.hsd1.or.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Jun 2011 02:42:39 +0200 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: emacs-orgmode@gnu.org Eric Schulte writes: >>> >>> I like the concision of the "=original-name" syntax used by noweb, but I >>> would lean towards the use of a ":noweb-append" type header argument as >>> suggested above because currently the names of blocks in Babel carry no >>> semantic content and I'd prefer to leave it this way. >> >> I suppose it may also break compatibility in case someone out there uses >> the =symbol. >> >> Had it been thought of earlier, I would have preferred the default >> behavior being append if you have multiple blocks of the same name, and >> an explicit option *not* to append but to overwrite, but your idea makes >> the most sense with respect to preserving backward compatibility. >> >> In addition to append, there probably should be another option for >> overwriting instead of appending (neither is possible right now). >> > > I've just pushed up a patch which implements optional block combination > during tangling. Specifically a new customization variable named > `org-babel-tangle-named-block-combination' is introduced which can take > the following values This does solve the problems I have, but I think the noweb-append header option discussed earlier is much more flexible. The potential problems with a custom variable is that it can't be set at a per-buffer or per-document level. I was thinking along the lines of: :noweb-append option where option is one of: - nil (the default) - append (appends to the block of the same name as it is up to that point in the document - acts as nil if this is the first block of that name). - overwrite (overwrites the block as it is up to that point - acts as nil if this is the first block). I think these three provide all the abilities of what you proposed, but allows for much more. Some additional benefits: 1. Can be set at a per-buffer level or a per-block level. 2. Can selectively append/overwrite. One scenario where this would be useful is where you may have had some source blocks that had been appended, but then later on as the project evolves, you decide to rewrite much of that code. You can then just do an overwrite (i.e. erases all that you had up to that point), and then again allow for the new code to be evolved with possible future appends (so multiple appends/overwrites in one document). You may have reason to keep the old code in the document for some reason or other. If that didn't make sense I can explain in more detail. > Hopefully this gets at the behavior you're after. I'd be interested to > hear any thought you have on this new functionality. I don't want to make it sound like I'm complaining above. What you've proposed probably takes care of my current needs (and I imagine is a bit easier to code than what I've proposed) - but I just think having a new header for the source block would make it much more flexible. I haven't yet tried the new patch - I'll have to figure out how to do a custom babel install (at the moment I get it via orgmode which is installed system-wide). Is it possible for me to just install babel in my custom emacs directory and not have it impact other aspects of org-mode? Thanks for the quick commit! -- My neighbor has a circular driveway. He never leaves home.