From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: Literate Programming - Continue a Source Block?
Date: Tue, 14 Jun 2011 22:48:35 +0200 [thread overview]
Message-ID: <87ei2wgmvw.fsf@Rainer.invalid> (raw)
In-Reply-To: 87tybtidzy.fsf@gmail.com
Eric Schulte <schulte.eric@gmail.com> writes:
> Thanks for sharing your thoughts. How would you feel about moving away
> from special source block names and moving towards implementing this
> behavior with a header argument?
I'm not feeling strongly either way... I'm wanting to use Babel for some
stuff at work, but haven't got around to learn it well enough to set
things in motion. So my current investment is still small. :-)
> Specifically two header arguments
> which would both take the name of a named code block, these header
> arguments would be as follows
>
> - append :: will append the current code block's body to the named code
> block during tangling
>
> - overwrite :: will overwrite the named code block's body with the body
> of the current code block
>
> for simple concatenate the value of the append header argument could be
> easily set on the file or subtree level.
This looks good, but it sort of turns the tables (I hope I get this
right, it was a longer day than I hoped). With noweb references, you
need to resolve the name of the source block at the target. With the
header arguments you propose you need to resolve the target block name
at the source. Both ways are useful, but it seems that it would be
difficult to track all targets from a single source even if supposedly
one could have a list of targets (that would only be useful for
"overwrite" unless you are really lucky). This asymmetry is
inescapeable when you try to use source blocks like "include files".
Another problem arises when you need to (again) reorder source blocks at
the target. You can't do that from the source, since not only would the
source then need to know all targets, it would also need to know all
other sources and their ordering in all targets.
> I feel that for many reasons (most of which have been discussed in
> relation to a header argument solution earlier in this thread) such a
> solution would be simpler and more consistent with the rest of Babel
> than the current name-based solution.
I'd think if there was an API to get at the contents of the header
arguments (perhaps using or modeled after the properties API), both the
forward and backward resolution could use the same internal mechanism
and noweb references could be changed (or extended) to (optionally) use
a match with some header argument (e.g. :id or :srcname). So let's say
that'd then allow:
<<:id "bla">>
to build a list of all source blocks with that header argument and
tangle them in list order. And since noweb references now really expect
a list, you can just as well feed them a custom function that cobbles
that list from multiple header arguments or properties.
Thinking along those lines I'm beginning to wonder if not the whole
header should be put into a drawer (I've often wished this was the case
for #+TBLFM).
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
next prev parent reply other threads:[~2011-06-14 20:48 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 [this message]
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
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=87ei2wgmvw.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--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).