From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Literate Programming - Continue a Source Block? Date: Sat, 11 Jun 2011 14:08:46 -0600 Message-ID: <871uz0m8q9.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:36780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVUUk-0004uT-P6 for emacs-orgmode@gnu.org; Sat, 11 Jun 2011 16:09:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QVUUj-0003mC-FC for emacs-orgmode@gnu.org; Sat, 11 Jun 2011 16:09:22 -0400 Received: from mail-yw0-f41.google.com ([209.85.213.41]:58859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVUUj-0003m7-AG for emacs-orgmode@gnu.org; Sat, 11 Jun 2011 16:09:21 -0400 Received: by ywb26 with SMTP id 26so2017619ywb.0 for ; Sat, 11 Jun 2011 13:09:20 -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: Neeum Zawan Cc: emacs-orgmode@gnu.org Hi Neeum, Thanks for your feedback. Your point is well taken about the flexibility of header arguments, and the ability of a header argument based solution to overwrite blocks. I would mention that variables such as the newly introduced `org-babel-tangle-named-block-combination' may be easily set on a per-file bases using file local variables---basically adding a line like the following to the top of your Org-mode file. # -*- org-babel-tangle-named-block-combination:append -*- While there is no way to specify this on the block level, I would tend to think that specifications such as ":tangle no" or simply renaming the block would suffice in most cases. This still does not address the subtree level. I think that a general solution for setting variable values at the subtree level might be widely useful and could be something worth pursuing Org-wide. Moving forward from here, my proposal would be that we all try out the current support using noweb references and the new named-block behavior and discover experientially if and what new features would be desirable. On a related note I hereby declare that the newly implemented named-block behavior should be considered experimental, and support for it may be removed if a better solution presents itself. Cheers -- Eric Neeum Zawan writes: > 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! -- Eric Schulte http://cs.unm.edu/~eschulte/