Shiyuan <gshy2...@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
