From: Neeum Zawan <mailinglists@nawaz.org>
To: emacs-orgmode@gnu.org
Subject: Re: Literate Programming - Continue a Source Block?
Date: Wed, 08 Jun 2011 08:20:14 -0700 [thread overview]
Message-ID: <87fwnkjqoh.fsf@fester.com> (raw)
In-Reply-To: 80k4cw22uf.fsf@somewhere.org
"Sebastien Vauban"
<wxhgmqzgwmuf@spammotel.com> writes:
> Hi Neeum,
>
> Neeum Zawan wrote:
>> With noweb, one can continue a source block that one started
>> earlier. Can this not be done with Babel?
>>
>> If not, I'm struggling a little with how to do LP using Babel...
>
> Of course, this can be done here as well: simply reuse the same "tangle"
> target (file), and blocks are concatenated in the order they appear.
But this will only allow me to append to the end of the file (up to that
point), correct? I want to append to a source block that may be in the
middle. Consider the following example:
(Begin-example)
#+BABEL: :noweb yes
* Outline
The structure of the configuration file will be:
#+srcname: outline
#+begin_src emacs-lisp :tangle .emacs :exports code
;; Store configurations that impact appearance
<<visual-config>>
;; Languages configurations
<<lang-config>>
;; GNUS configurations
<<gnus-config>>
#+end_src
* General Appearance
This section controls the general appearance (color of cursor, fonts,
etc).
#+srcname: visual-config
#+begin_src emacs-lisp :exports code
;; Config here.
#+end_src
* GNUS configuration
#+srcname: gnus-config
#+begin_src emacs-lisp :exports code
;; Config here.
#+end_src
* Languages
#+srcname: lang-config
#+begin_src emacs-lisp :exports code
<<python-config>>
<<perl-config>>
#+end_src
** Python
Now here's where the problem begins. I want to add some configurations
that impact some Python settings. I can dump those in
python-config. However, I also want to add some visual settings for
python-mode (change font colors, etc). For whatever reason, I think that
part should go into visual-config.
How do I now append the relevant portion to visual-config while I'm in
_this_ portion of the org document?
(End-example)
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.
> 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.
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.
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.
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. 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?
next prev parent reply other threads:[~2011-06-08 15:18 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 [this message]
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
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=87fwnkjqoh.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).