From: "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: [New exporter] Wrong export to LaTeX
Date: Tue, 16 Oct 2012 09:49:03 +0200 [thread overview]
Message-ID: <80391eg8ls.fsf@somewhere.org> (raw)
In-Reply-To: 871ugzfovj.fsf@gmail.com
Hi Nicolas,
Nicolas Goaziou wrote:
> "Sebastien Vauban" writes:
>> Suvayu Ali wrote:
>>>> However, I thought that LaTeX_CLASS had been renamed EXPORT_LaTeX_CLASS,
>>>> but when using the latter, I get frames inside an `article' documentclass
>>>> type of document -- while using `C-c E l O' (for Beamer)? That results in
>>>> a weird document...
>>>
>>> I believe that is the property name only for subtree export. So when
>>> exporting a file, use:
>>>
>>> #+LaTeX_CLASS: beamer
>>>
>>> for subtree export use:
>>>
>>> * Beamer presentation
>>> :PROPERTIES:
>>> :EXPORT_LaTeX_CLASS: beamer
>>> :END:
>>
>> Nicolas, do you confirm the fact that keywords differ whether they apply to
>> the file or to a subtree?
>
> Yes.
>
>> If yes, wouldn't make sense to remove such a distinction, or (at the other
>> extreme of the spectrum) to make all keywords share that same feature
>> (prefixing with "EXPORT_" for subtrees)?
>
> Note that it isn't a new feature from the new export engine, merely a
> generalization from the old exporter, which already distinguished #+DATE:
> and :EXPORT_DATE:, #+TITLE: and :EXPORT_TITLE:...
>
> There's little incentive for users to create new keywords on the fly. On the
> other hand, they may want to add node properties. That's why export keywords
> should be made as simple as possible and export properties should pollute as
> little namespace as possible.
>
> Therefore, I think the current state is good. It will be properly documented
> once the new exporter becomes mainstream (but the rule is simple anyway).
I'm glad that such a rule exists:
#+KEYWORD: for *file* export properties
|
v
#+EXPORT_KEYWORD: for *subtree* export properties
#+LaTeX_CLASS follows a rule which escaped me.
Your explanation does make a lot of sense. No change!
Best regards,
Seb
--
Sebastien Vauban
next prev parent reply other threads:[~2012-10-16 7:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-11 13:04 [New exporter] Wrong export to LaTeX Sebastien Vauban
2012-10-11 13:21 ` Nicolas Goaziou
2012-10-11 16:52 ` Suvayu Ali
2012-10-11 17:54 ` Nicolas Goaziou
2012-10-12 10:24 ` Suvayu Ali
2012-10-12 11:06 ` Sebastien Vauban
2012-10-12 11:32 ` Sebastien Vauban
2012-10-12 11:51 ` Nicolas Goaziou
2012-10-12 12:15 ` Suvayu Ali
2012-10-12 12:05 ` Suvayu Ali
2012-10-15 20:23 ` Sebastien Vauban
2012-10-15 20:42 ` Nicolas Goaziou
2012-10-16 7:49 ` Sebastien Vauban [this message]
2012-10-12 12:09 ` Nicolas Goaziou
2012-10-12 12:19 ` Suvayu Ali
2012-10-11 13:45 ` Suvayu Ali
2012-10-11 14:41 ` Sebastien Vauban
2012-10-11 15:35 ` Suvayu Ali
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80391eg8ls.fsf@somewhere.org \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.