From: Shiyuan <gshy2014@gmail.com>
To: Thorsten Jolitz <tjolitz@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: LaTex best practice in org-mode
Date: Mon, 23 Jun 2014 23:02:43 -0700 [thread overview]
Message-ID: <CAOm4EMsrFR7BvFyOzaqS-hnThefL34KgbxsZtU2imWv0twe0xA@mail.gmail.com> (raw)
In-Reply-To: <874mzdnynh.fsf@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 --]
next prev parent reply other threads:[~2014-06-24 6:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-22 6:12 LaTex best practice in org-mode Shiyuan
2014-06-22 8:20 ` Thorsten Jolitz
2014-06-24 6:02 ` Shiyuan [this message]
2014-06-24 8:52 ` Thorsten Jolitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOm4EMsrFR7BvFyOzaqS-hnThefL34KgbxsZtU2imWv0twe0xA@mail.gmail.com \
--to=gshy2014@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=tjolitz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).