emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Sébastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Sébastien Vauban"
	<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>,
	emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: **: Re: Re: Org-mode Code Blocks Manuscript: Request For Comments
Date: Thu, 09 Dec 2010 14:22:51 +0100	[thread overview]
Message-ID: <8039q7dqs4.fsf@missioncriticalit.com> (raw)
In-Reply-To: <87bp4w0zmx.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (Eric Schulte's message of "Wed, 08 Dec 2010 12:55:07 -0700")

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

  parent reply	other threads:[~2010-12-09 13:22 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 [this message]
2010-12-09 14:46           ` **: " Eric Schulte
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=8039q7dqs4.fsf@missioncriticalit.com \
    --to=wxhgmqzgwmuf-genee64ty+gs+fvcfc7uqw@public.gmane.org \
    --cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \
    --cc=schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@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).