From: Neeum Zawan <mailinglists@nawaz.org>
To: emacs-orgmode@gnu.org
Subject: Re: Literate Programming - Continue a Source Block?
Date: Fri, 10 Jun 2011 17:44:45 -0700 [thread overview]
Message-ID: <87fwnhgps2.fsf@fester.com> (raw)
In-Reply-To: 877h8tv6yh.fsf@gmail.com
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!
--
My neighbor has a circular driveway. He never leaves home.
next prev parent reply other threads:[~2011-06-11 0:42 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 [this message]
2011-06-11 20:08 ` Eric Schulte
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=87fwnhgps2.fsf@fester.com \
--to=mailinglists@nawaz.org \
--cc=emacs-orgmode@gnu.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).