From: "Sébastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: Org-mode Code Blocks Manuscript: Request For Comments
Date: Thu, 09 Dec 2010 20:48:22 +0100 [thread overview]
Message-ID: <80mxoeybg9.fsf@missioncriticalit.com> (raw)
In-Reply-To: 87bp4w0zmx.fsf@gmail.com
Hi Eric,
"Eric Schulte" wrote:
> Thanks for the proof reading. I have answers for some of your questions
> below.
Sure!
>> Page 9 -- You say that "tags and properties of a node are inherited by its
>> sub-nodes". I agree for tags, not for properties (at least, by default).
>
> With respect to code blocks properties are inherited by subnodes, at
> least all properties which can be used as header arguments are
> inherited.
OK. You're talking now of the properties *of code blocks*. The, your paragraph
is a bit misleading, as you're also talking of tags -- which do not apply to
code blocks...
Having made the above distinction, I now understand your paragraph.
>> BTW, what happens if there is a name clash with other code blocks (in the same
>> document, or in the LOB)? Though, this is not for your paper...
>
> While no behavior is guaranteed in this case (meaning don't do it :)) I
> believe that whichever code block is found first will be used, in
> practice this would probably mean that local code blocks will override
> lob code blocks, but I make no guarantees
Some ideas:
- report the conflict in a very visible way (at execution and export times)
- having the ability to look for potential clashes (some
=list-code-block-shadows=)
- (why not?) being able to add the filename of the code block we want to use,
to resolve the conflict (if we don't want to change the names...)
>> Side comment -- Wouldn't you use a standard way of handling the acronyms in
>> LaTeX, so that they're expanded when required, and listed at the end of the
>> document? Example of such acro: ESS.
>
> I don't understand what you mean by "standard acronyms" can you give a
> specific location and how you would suggest it be changed?
#+TITLE: Inserting proper acronyms in LaTeX
#+DATE: 2010-12-09
#+LANGUAGE: en_US
#+LaTeX_HEADER: \usepackage[printonlyused]{acronym}% (not in medium TeX Live installation)
* Prologue
\ac{ESS} is a great add-on to Emacs.
* Epilogue
Emacs is made public by the \ac{FSF}. The second time the acronym \ac{FSF} is
used, it should not be expanded in the PDF...
All of that being taken care automagically by LaTeX itself, and the =acronym=
package. Plus you gain hyperlinks from every usage of acronym to its
definition table...
* Acronyms
\begin{acronym}[LONGEST]
\acro{EEPROM} {Electrically Erasable Programmable \acs{ROM}}
\acro{ESS} {Emacs Speaks Statistics}
\acro{FSF} {Free Software Foundation}
\acro{GNU} {GNU is Not Unix}
\end{acronym}
** Note :noexport:
Unused acronyms won't be outputted in the final PDF... Out of the 4 defined
acronyms, only the 2 used will be listed at the end of the document... thanks
to the option =printonlyused=.
* Conclusion
Does this answer your question?
For me, this is one of the only missing piece that should be made more
standard into Org.
The real problem is: how do we have something clean for the HTML export, even
if ultra-minimal (like having no LaTeX symbols outputted in the middle of the
text, having always/never acronym expansion, printing all acronyms
independently of the fact they're used or not).
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
next prev parent reply other threads:[~2010-12-09 19:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-02 19:28 Org-mode Code Blocks Manuscript: Request For Comments Eric Schulte
2010-12-02 19:36 ` Jeff Horn
2010-12-02 23:13 ` Eric S Fraga
2010-12-03 1:17 ` Thomas S. Dye
2010-12-03 12:26 ` Eric S Fraga
2010-12-03 17:29 ` Thomas S. Dye
2010-12-03 20:07 ` Eric S Fraga
2010-12-03 7:16 ` Nick Dokos
2010-12-07 22:55 ` Sébastien Vauban
2010-12-08 16:33 ` Thomas S. Dye
2010-12-08 19:55 ` Eric Schulte
[not found] ` <87bp4w0zmx.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-12-09 13:22 ` **: " Sébastien Vauban
2010-12-09 14:46 ` Eric Schulte
2010-12-09 19:48 ` Sébastien Vauban [this message]
2010-12-08 19:54 ` Eric Schulte
2010-12-03 7:58 ` Detlef Steuer
2010-12-05 6:03 ` Thomas S. Dye
2010-12-06 19:52 ` Charles C. Berry
2010-12-07 0:13 ` Sunny Srivastava
2010-12-07 4:48 ` Charles C. Berry
2010-12-07 14:24 ` Thomas S. Dye
2010-12-07 17:05 ` Charles C. Berry
2010-12-09 7:20 ` Charles C. Berry
2010-12-09 8:07 ` Thomas S. Dye
2010-12-06 2:02 ` Christopher Allan Webber
2010-12-08 19:54 ` Eric Schulte
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=80mxoeybg9.fsf@missioncriticalit.com \
--to=wxhgmqzgwmuf-genee64ty+gs+fvcfc7uqw@public.gmane.org \
--cc=emacs-orgmode-mXXj517/zsQ@public.gmane.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).