Re: LaTex best practice in org-mode

[Thorsten Jolitz <tjolitz@gmail.com>]

Shiyuan <gshy2014@gmail.com> writes:

Hi,

> We can write LaTex directly in org-mode without put it in a SRC block.
> When the code is exported, the latex syntax will be handled correctly
> to html or pdf. That's very nice part of org mode. However, if we don't
> put the latex code into a SRC block, the latex syntax is not correctly
> highlighted (in the code attached below, the first equation is not
> highlighted). Another benefit of putting the latex code into SRC block
> is that we can easily switch to the latex mode to edit the code
> snippet using C-c ' and in the latex mode, we can use some full-fleged
> latex package like auctex. However, the latex code in the SRC block is
> ignored when exported to html. For example, when I exported the
> following to html, the first equation shows up in the html but the
> second seconed does not. Any way to make the html exporter to
> generated the second equation too without taking away the
> BEGIN_SRC/END_SRC? What's the best practice to write latex in
> org-mode. Thanks. 
>
> \begin{equation}
> \label{eq:test}
> Bx=b
> \end{equation}
>
> #+BEGIN_SRC latex 
>
> \begin{equation}
> \label{eq:test}
> Ax=b
> \end{equation}
> #+END_SRC

When you know how to write Emacs Lisp, you should probably define a
derived export backend from ox-html:

,----[ C-h f org-export-define-derived-backend RET ]
| org-export-define-derived-backend is a compiled Lisp function in
| `ox.el'.
| 
| (org-export-define-derived-backend CHILD PARENT &rest BODY)
| 
| Create a new back-end as a variant of an existing one.
| 
| CHILD is the name of the derived back-end.  PARENT is the name of
| the parent back-end.
| 
| BODY can start with pre-defined keyword arguments.  The following
| keywords are understood:
| 
|   :export-block
| 
|     String, or list of strings, representing block names that
|     will not be parsed.  This is used to specify blocks that will
|     contain raw code specific to the back-end.  These blocks
|     still have to be handled by the relative `export-block' type
|     translator.
| 
|   :filters-alist
| 
|     Alist of filters that will overwrite or complete filters
|     defined in PARENT back-end.  See `org-export-filters-alist'
|     for a list of allowed filters.
| 
|   :menu-entry
| 
|     Menu entry for the export dispatcher.  See
|     `org-export-define-backend' for more information about the
|     expected value.
| 
|   :options-alist
| 
|     Alist of back-end specific properties that will overwrite or
|     complete those defined in PARENT back-end.  Refer to
|     `org-export-options-alist' for more information about
|     structure of the values.
| 
|   :translate-alist
| 
|     Alist of element and object types and transcoders that will
|     overwrite or complete transcode table from PARENT back-end.
|     Refer to `org-export-define-backend' for detailed information
|     about transcoders.
| 
| As an example, here is how one could define "my-latex" back-end
| as a variant of `latex' back-end with a custom template function:
| 
|   (org-export-define-derived-backend 'my-latex 'latex
|      :translate-alist '((template . my-latex-template-fun)))
| 
| The back-end could then be called with, for example:
| 
|   (org-export-to-buffer 'my-latex "*Test my-latex*")
| 
| [back]
`----

and in that backend do only one thing, define a new transcode function
for element `src-block'

,----[ C-h v org-element-all-elements RET ]
| org-element-all-elements is a variable defined in `org-element.el'.
| Its value is (babel-call center-block clock comment comment-block
| diary-sexp drawer dynamic-block example-block export-block fixed-width
| footnote-definition headline horizontal-rule inlinetask item keyword
| latex-environment node-property paragraph plain-list planning
| property-drawer quote-block section special-block src-block table
| table-row verse-block)
| 
| 
|   This variable may be risky if used as a file-local variable.
| 
| Documentation:
| Complete list of element types.
| 
| [back]
`----

that uses this function to export a src-block with ox-latex

,----[ C-h f org-export-with-backend RET ]
| org-export-with-backend is a compiled Lisp function in `ox.el'.
| 
| (org-export-with-backend BACKEND DATA &optional CONTENTS INFO)
| 
| Call a transcoder from BACKEND on DATA.
| BACKEND is an export back-end, as returned by, e.g.,
| `org-export-create-backend', or a symbol referring to
| a registered back-end.  DATA is an Org element, object, secondary
| string or string.  CONTENTS, when non-nil, is the transcoded
| contents of DATA element, as a string.  INFO, when non-nil, is
| the communication channel used for export, as a plist.
| 
| [back]
`----

whenever

,----[ C-h f org-element-property RET ]
| org-element-property is a compiled Lisp function in `org-element.el'.
| 
| (org-element-property PROPERTY ELEMENT)
| 
| Extract the value from the PROPERTY of an ELEMENT.
| 
| [back]
`----

returns 'latex  for property :language.

But maybe a simple filter could the work too and somebody with deeper
insights gives you better advice ...

-- 
cheers, 
Thorsten