[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Literate Programming - Continue a Source Block?
From: |
Eric Schulte |
Subject: |
Re: [O] Literate Programming - Continue a Source Block? |
Date: |
Sat, 11 Jun 2011 14:08:46 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
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 <address@hidden> writes:
> Eric Schulte <address@hidden> 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/
- Re: [O] Literate Programming - Continue a Source Block?, (continued)
- Re: [O] Literate Programming - Continue a Source Block?, Eric Schulte, 2011/06/10
- Re: [O] Literate Programming - Continue a Source Block?, Achim Gratz, 2011/06/12
- Re: [O] Literate Programming - Continue a Source Block?, Eric Schulte, 2011/06/13
- Re: [O] Literate Programming - Continue a Source Block?, Achim Gratz, 2011/06/14
- Re: [O] Literate Programming - Continue a Source Block?, Eric Schulte, 2011/06/15
- Re: [O] Literate Programming - Continue a Source Block?, Achim Gratz, 2011/06/15
- Re: [O] Literate Programming - Continue a Source Block?, Eric Schulte, 2011/06/16
- Re: [O] Literate Programming - Continue a Source Block?, Neeum Zawan, 2011/06/15
- Re: [O] Literate Programming - Continue a Source Block?, Neeum Zawan, 2011/06/10
- Re: [O] Literate Programming - Continue a Source Block?, Neeum Zawan, 2011/06/10
- Re: [O] Literate Programming - Continue a Source Block?,
Eric Schulte <=
- Re: [O] Literate Programming - Continue a Source Block?, Neeum Zawan, 2011/06/12
- Re: [O] Literate Programming - Continue a Source Block?, Eric Schulte, 2011/06/13
- Re: [O] Literate Programming - Continue a Source Block?, Neeum Zawan, 2011/06/15
- Re: [O] Literate Programming - Continue a Source Block?, Eric Schulte, 2011/06/15
- Re: [O] Literate Programming - Continue a Source Block?, Neeum Zawan, 2011/06/15
- Re: [O] Literate Programming - Continue a Source Block?, Eric Schulte, 2011/06/16
- Re: [O] Literate Programming - Continue a Source Block?, Neeum Zawan, 2011/06/17
- Re: [O] Literate Programming - Continue a Source Block?, Eric Schulte, 2011/06/17
- Re: [O] Literate Programming - Continue a Source Block?, Sebastien Vauban, 2011/06/17
- Re: [O] Literate Programming - Continue a Source Block?, Neeum Zawan, 2011/06/19