LaTex best practice in org-mode

LaTex best practice in org-mode

[Shiyuan]

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

Hi all,
Hi all,
   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

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

Re: LaTex best practice in org-mode

[Thorsten Jolitz]

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

Re: LaTex best practice in org-mode

[Shiyuan]

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

Re: LaTex best practice in org-mode

[Thorsten Jolitz]

Shiyuan <gshy2014@gmail.com> writes:

Hi Shiyuan,

> Thank you very much for the detailed step-by-step instructions. I will
> try it out. 

you might actually start with reading about filters 

,----
| http://orgmode.org/worg/dev/org-export-reference.html
`----

maybe thats all you need. 

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

I used rebox2 quite a while but then discovered boxquote recently,
which seems even better and allows for this [C-h f function-name RET]
boxes. 

In my init.el I have

,----
|    (global-set-key (kbd "C-c b k") 'boxquote-describe-key)
|    (global-set-key (kbd "C-c b f") 'boxquote-describe-function)
|    (global-set-key (kbd "C-c b v") 'boxquote-describe-variable)
|    (global-set-key (kbd "C-c b b") 'boxquote-buffer)
|    (global-set-key (kbd "C-c b r") 'boxquote-region)
|    (global-set-key (kbd "C-c b x") 'boxquote-unbox-region)
|    (global-set-key (kbd "C-c b d") 'boxquote-defun)
|    (global-set-key (kbd "C-c b p") 'boxquote-paragraph)
|    (global-set-key (kbd "C-c b q") 'boxquote-fill-paragraph)
|    (global-set-key (kbd "C-c b s") 'boxquote-shell-command)
|    (global-set-key (kbd "C-c b h") 'boxquote-quote-help-buffer)
|    (global-set-key (kbd "C-c b n") 'boxquote-narrow-to-boxquote)
|    (global-set-key (kbd "C-c b u") 'boxquote-unbox)
|    (global-set-key (kbd "C-c b e") 'boxquote-text)
|    (global-set-key (kbd "C-c b i") 'boxquote-title))
`----

but did not try all of them yet. 

> 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


-- 
cheers,
Thorsten