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

["Eric Schulte" <schulte.eric@gmail.com>]

Hi Seb,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

> 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.
>

Alright I'll take another look at this paragraph and see if I can
untangle the verbiage.

>
>>> 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...)
>

actually this should already be implemented, you can specify another
file by constructing your reference as file-name:resource-name, e.g.

with the following saved to ~/Desktop/location.org

  #+source: year
  #+begin_src emacs-lisp
    2010
  #+end_src

  #+source: city
  #+begin_src emacs-lisp
    "Santa Fe"
  #+end_src

the following code block should resolve its references correctly from
*any* buffer

  #+headers: :var city=~/Desktop/location.org:city
  #+headers: :var year=~/Desktop/location.org:year
  #+begin_src emacs-lisp
    (message "I'm in %s in the year %d" city year)
  #+end_src

although apparently there is still some work to be done on this code as
for me it leaves the referenced file open.  This is code that apparently
hasn't been used or documented so I'm sure there will be some kinks to
work out

>
>>> 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?
>

Yes, thanks for the explanation, this is the first I've heard of this
package but it certainly does seem useful.

>
> 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).
>

Maybe this would be possible to implement using custom links?

Cheers -- Eric

>
> Best regards,
>   Seb