Re: LaTex best practice in org-mode

[Shiyuan <gshy2014@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5737 bytes --]

Hi Thorsten,
Thank you very much for the detailed step-by-step instructions. I will try
it out.
BTW: your email is very well-structured . Do you write your email in
org-mode or some other emacs mode which can recognize  [C-h f function-name
RET] and insert the results into the email?

Shiyuan


On Sun, Jun 22, 2014 at 1:20 AM, Thorsten Jolitz <tjolitz@gmail.com> wrote:

> 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 6966 bytes --]