From: "Eric Schulte" <schulte.eric@gmail.com>
To: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: **: Re: Re: Org-mode Code Blocks Manuscript: Request For Comments
Date: Thu, 09 Dec 2010 07:46:00 -0700 [thread overview]
Message-ID: <87hbenypg7.fsf@gmail.com> (raw)
In-Reply-To: <8039q7dqs4.fsf@missioncriticalit.com> ("Sébastien Vauban"'s message of "Thu, 09 Dec 2010 14:22:51 +0100")
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
next prev parent reply other threads:[~2010-12-09 14:46 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 [this message]
2010-12-09 19:48 ` Sébastien Vauban
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=87hbenypg7.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--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).