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: Wed, 08 Jun 2011 13:40:16 -0600 [thread overview]
Message-ID: <87mxhsnmcf.fsf@gmail.com> (raw)
In-Reply-To: <87fwnkjqoh.fsf@fester.com> (Neeum Zawan's message of "Wed, 08 Jun 2011 08:20:14 -0700")
>
> The above is somewhat artificial, but in a proper programming project
> something like this will occur frequently: A new feature will be added
> at some later point and I'll want to update various blocks of code.
>
Currently the best method is that suggested previously/below of using
named references in the target code block, as suggested below. While it
shouldn't be overly difficult to add the behavior your described with
something like a ":noweb-append" header argument, e.g.,
#+begin_src emacs-lisp :noweb-append visual-config
...
#+end_src
This behavior is not currently implemented.
>
>> Second solution: create one sole block that will be tangled, and which
>> contains your other blocks (using the <<ref>> syntax), in the order you want.
>
> I had thought of this, but I find it somewhat lacking. Consider my
> example above. I could have created a <<visual-python>> in my
> <<visual-config>> block. However:
>
> 1. That requires me to know I'm going to need it later when I write
> visual-config.
>
nit picking here, but while this does require a small edit to
<<visual-config>>, there is no need for prior knowledge of the need for
<<visual-python>>.
>
> 2. If I didn't know I'd need it, I'd have to continually modify various
> parts of the org document every time I add a new feature to my code. I
> find this suboptimal and error prone.
>
Technically only one edit per new block introduced, which does not seem
overly onerous.
>
> 3. For me, one of the main motivations to do LP is to document the
> evolution of the project, such that someone else can read the document
> and understand. Part of this is that I want all aspects of a single
> feature to appear under a single heading. When the reader reads the
> document, he shouldn't have to see too many aspects of the code early on
> that will be explained much later in the document.
>
I agree, this is a motivating example.
>
> Now the original noweb allows what I'm asking for. If you begin a
> source block with a name of an existing block but append an "="
> symbol, it knows to append to that source block.
>
> It would be great if org-mode could add that capability.
I agree, and the functionality you describe shouldn't be overly
difficult to implement.
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.
> Another approach is that if multiple source blocks with the same name
> are found, the default behavior is to concatenate all those source
> blocks together (and then add a header option for overwrite if the
> user wanted to overwrite instead of append).
>
> Thoughts?
>
Thanks for the motivating example and the thorough explanation of
behavior.
I'll certainly put this on my long-term development queue, however, that
does not guarantee an implementation in the near future. If anyone is
interested in this functionality and is up for writing some elisp I am
happy to offer advice and code pointers immediately.
Best -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
next prev parent reply other threads:[~2011-06-08 19:40 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 [this message]
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
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=87mxhsnmcf.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).