Hi Bastien, My use-case is that I need to write a document that needs to be output to various styles (all using LaTeX). Each style may use a different class and set of packages. And each defines a different set of commands, with different syntax, to format the contents (they are not standard as \section, etc.) Of course I don't want to re-write the same contents for each style, so I defined a common command interface such that I could write the contents as \contentBlockOne{\textbf{Bold text}} and implemented the interface for each specific style.
That has been working very well until I need to also output the contents to HTML. I thought it would be great to migrate the contents to orgmode, then export to LaTeX or HTML. But I need to re-use the common interface, so I defined orgmode macros to be able to write: {{{contentBlockOne(*Bold text*)}}} or {{{contentBlockOneBegin}}} *Bold text* {{{contentBlockOneEnd}}} The macros will be expanded to LaTeX commands or HTML markups accordingly. The problem is that orgmode markups inside LaTeX or HTML fragments are not converted. And I cannot use \textbf because it will not be translated to HTML. However, I've just discovered that while markups like *bold*, /italic/... are not converted, other markups like lists are. For example: \mycommand{*Bold* - Item 1 - Item 2 } is exported as \mycommand{\textbf{Bold} \begin{itemize} \item Item 1 \item Item 2 \end{itemize} } So it seems a bit inconsistent. If there is any solution or workaround for my problem, please let me know. Thanks, -- Truong Nghiem On Thu, Mar 8, 2012 at 7:46 AM, Bastien <b...@gnu.org> wrote: > Hi Truong, > > Truong Nghiem <truong.ngh...@gmail.com> writes: > >> Is there any way to turn on orgmode markups inside LaTeX fragments for >> export? For example, when I write >> \mycommand{*Bold text*} >> in an org file and export it to LaTeX, I would like to have >> \mycommand{\textbf{Bold text}} >> Currently it is exported as-is (verbatim): >> \mycommand{*Bold text*} > > There is no way to achieve this right now, and I think it would be > confusing to support mixed syntax. But I'm open to better use-cases. > > Thanks, > > -- > Bastien