From: Eric Schulte <eric.schulte@gmx.com>
To: "Thomas S. Dye" <tsd@tsdye.com>
Cc: Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>, emacs-orgmode@gnu.org
Subject: Re: :noweb header argument
Date: Tue, 10 Jan 2012 09:44:05 -0700 [thread overview]
Message-ID: <87ty43ik2y.fsf@gmx.com> (raw)
In-Reply-To: <m1boqba7ks.fsf@tsdye.com> (Thomas S. Dye's message of "Tue, 10 Jan 2012 05:41:23 -1000")
tsd@tsdye.com (Thomas S. Dye) writes:
> Hi Seb,
>
> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
>
>> Hi Thomas,
>>
>> Thomas S. Dye wrote:
>>> Is there a difference between :noweb tangle and :noweb no?
>>
>> Yes: ":noweb no" is the default, and must *not expand* anything.
>>
>>> Based on the documentation and some limited testing, I made the following
>>> table.
>>>
>>> *** :noweb parameters
>>>
>>> | param | eval | tangle | export |
>>> |--------+------+--------+--------|
>>> | yes | + | + | + |
>>> | no | - | + | - |
>>
>> It should be "-", "-", "-" here, if "-" means "no expansion".
>>
>
> Hmm, the manual entry for :noweb no says "However, noweb references will
> still be expanded during tangling." You're right, though, :noweb no
> doesn't expand noweb references during tangling. I'll work up a manual
> patch.
>
Great, I'll apply your documentation patch.
>
>
>>> | tangle | - | + | - |
>>> |--------+------+--------+--------|
>>> | need | + | + | - |
>>>
What should the name for such an option be?
>>>
>>> I think it might be good to have a parameter that expands noweb
>>>references on evaluation and tangling, but leaves them alone during
>>>export. This way the code block would be fully functional, but
>>>wouldn't duplicate code during export (when the noweb references are
>>>to other code blocks in the same document).
>>
>> I'd find that interesting as well, but then the names of the code blocks must
>> be visible again (in HTML and PDF exports), something that has disappeared
>> over time.
>
> Alternatively for LaTeX, some way to wrap exported code blocks in a
> \begin{listing} ... \end{listing} environment, complete with caption and
> label. This way the code block name could appear in the caption, and
> with \listoflistings, in the document frontmatter as well.
>
As I recall this was originally implemented and then later removed
because it was causing more confusion and problems than it was worth. I
hope it hasn't crossed the line of existence more than once. At some
point it should be placed behind a user-customizable variable,
preferably something like `org-babel-export-code-format' which defaults
to something like "%code" but could be augmented to something like
"Block Name: *%name*\n %code". It is not immediately clear if such a
variable should have different values for different export backends or
(likely preferable) should expand into Org-mode text *before* export.
Cheers,
>
>>
>> Find attached the 2 PDF I had written (in 2009) for comparing NoWeb's
>> rendering of blocks and Babel's rendering. See
>> http://lists.gnu.org/archive/html/emacs-orgmode/2009-12/msg00170.html.
>>
>> Some time after that, we had block names in the HTML/PDF output, but not
>> anymore.
>>
>> Best regards,
>> Seb
>
> All the best,
> Tom
--
Eric Schulte
http://cs.unm.edu/~eschulte/
next prev parent reply other threads:[~2012-01-10 16:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-08 23:04 :noweb header argument Thomas S. Dye
2012-01-10 8:04 ` Sebastien Vauban
2012-01-10 8:24 ` Andreas Leha
2012-01-10 11:30 ` Eric S Fraga
2012-01-10 15:41 ` Thomas S. Dye
2012-01-10 16:44 ` Eric Schulte [this message]
2012-01-10 18:42 ` Thomas S. Dye
2012-01-11 8:09 ` Sebastien Vauban
2012-01-11 15:06 ` Eric S Fraga
2012-01-14 19:59 ` Eric Schulte
2012-01-14 23:06 ` Thomas S. Dye
2012-01-15 15:28 ` Eric Schulte
2012-01-18 10:03 ` Eric S Fraga
2012-01-18 19:11 ` Yagnesh Raghava Yakkala
2012-01-11 17:17 ` Eric Schulte
2012-01-10 21:04 ` Eric S Fraga
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=87ty43ik2y.fsf@gmx.com \
--to=eric.schulte@gmx.com \
--cc=emacs-orgmode@gnu.org \
--cc=tsd@tsdye.com \
--cc=wxhgmqzgwmuf@spammotel.com \
/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).