From: Eric Schulte <schulte.eric@gmail.com>
To: Neeum Zawan <mailinglists@nawaz.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Literate Programming - Continue a Source Block?
Date: Sat, 11 Jun 2011 14:08:46 -0600 [thread overview]
Message-ID: <871uz0m8q9.fsf@gmail.com> (raw)
In-Reply-To: 87fwnhgps2.fsf@fester.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/
next prev parent reply other threads:[~2011-06-11 20:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 5:47 Literate Programming - Continue a Source Block? Neeum Zawan
2011-06-08 7:34 ` Sebastien Vauban
2011-06-08 15:20 ` Neeum Zawan
2011-06-08 19:40 ` Eric Schulte
2011-06-08 21:20 ` Neeum Zawan
2011-06-10 4:55 ` Avdi Grimm
2011-06-10 19:09 ` Eric Schulte
2011-06-10 19:27 ` Achim Gratz
2011-06-10 20:00 ` Eric Schulte
2011-06-12 8:32 ` Achim Gratz
2011-06-13 22:04 ` Eric Schulte
2011-06-14 20:48 ` Achim Gratz
2011-06-15 17:23 ` Eric Schulte
2011-06-15 21:19 ` Achim Gratz
2011-06-16 4:54 ` Eric Schulte
2011-06-16 2:35 ` Neeum Zawan
2011-06-11 1:02 ` Neeum Zawan
2011-06-11 0:44 ` Neeum Zawan
2011-06-11 20:08 ` Eric Schulte [this message]
2011-06-12 5:36 ` Neeum Zawan
2011-06-13 21:57 ` Eric Schulte
2011-06-15 5:17 ` Neeum Zawan
2011-06-15 17:27 ` Eric Schulte
2011-06-15 19:37 ` Neeum Zawan
2011-06-16 2:26 ` Eric Schulte
2011-06-17 4:30 ` Neeum Zawan
2011-06-17 4:39 ` Eric Schulte
2011-06-17 7:00 ` Sebastien Vauban
2011-06-19 23:38 ` Neeum Zawan
2011-06-16 10:14 ` Olaf.Hamann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871uz0m8q9.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mailinglists@nawaz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).