Re: Org-mode Code Blocks Manuscript: Request For Comments

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