Re: Literate Programming - Continue a Source Block?

[Eric Schulte <schulte.eric@gmail.com>]

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 <mailinglists@nawaz.org> writes:

> Eric Schulte <schulte.eric@gmail.com> 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/