emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Re: [org-beamer] \alert


From: Eric S Fraga
Subject: Re: [Orgmode] Re: [org-beamer] \alert
Date: Tue, 26 Jan 2010 16:22:27 +0000
User-agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/23.1 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

At Tue, 26 Jan 2010 16:06:27 +0100,
Sébastien Vauban wrote:
> Eric S Fraga wrote:
> > At 24 Jan 2010 20:10:03 +0100,
> > Sven Bretfeld wrote:
> >> 
> >> Is there any Symbol in org-beamer for \alert{Text}? In presentations \alert

[...]

> >       org-export-latex-emphasis-alist (quote 
> >                                            (("*" "\\textbf{%s}" nil)
> >                                             ("/" "\\emph{%s}" nil) 
> >                                             ("_" "\\underline{%s}" nil)
> >                                             ("+" "\\texttt{%s}" nil)
> >                                             ("=" "\\verb=%s=" nil)
> >                                             ("~" "\\verb~%s~" t)
> >                                             ("@" "\\alert{%s}" nil))))
> >
> 
> That's what I'm using as well, but the problem is that it's not compatible
> anymore with non-beamer LaTeX, the alert macro being unknown.

Very true.  I've never thought about this as my presentations are for
presentation only etc.  However, it would definitely be nice to have a
more general solution.

> Would there be a way to conditionally translate @...@ to alert (if beamer) or
> to emph (if not-beamer), so that we can still easily compile a document to one
> or the other LaTeX "back-end", without having to customize variables in Emacs,
> prior to a compilation to the other "back-end"?

The alist structure doesn't allow for embedded lisp code, as far as I
can tell.  It would obviously be easier if this structure could be
evaluated on the fly.

> I must admit I do not have clear specifications on how to tell Org about such
> a config...

The only suggestion I can come up with would be to modify this
variable using, for instance, the org-export-later-after-initial-vars-hook?

eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]