Re: LaTex best practice in org-mode

[Thorsten Jolitz <tjolitz@gmail.com>]

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