From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shiyuan Subject: Re: LaTex best practice in org-mode Date: Mon, 23 Jun 2014 23:02:43 -0700 Message-ID: References: <874mzdnynh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113304ac47d02a04fc8eb58e Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzJos-0000SN-5s for emacs-orgmode@gnu.org; Tue, 24 Jun 2014 02:03:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzJop-0006LP-Ru for emacs-orgmode@gnu.org; Tue, 24 Jun 2014 02:03:02 -0400 Received: from mail-vc0-x22e.google.com ([2607:f8b0:400c:c03::22e]:55445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzJop-0006Ic-Ln for emacs-orgmode@gnu.org; Tue, 24 Jun 2014 02:02:59 -0400 Received: by mail-vc0-f174.google.com with SMTP id hy4so7124662vcb.19 for ; Mon, 23 Jun 2014 23:02:43 -0700 (PDT) In-Reply-To: <874mzdnynh.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Thorsten Jolitz Cc: emacs-orgmode@gnu.org --001a113304ac47d02a04fc8eb58e Content-Type: text/plain; charset=UTF-8 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 wrote: > Shiyuan 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 > > > --001a113304ac47d02a04fc8eb58e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Thorsten,=C2=A0
Thank you very much for the d= etailed step-by-step instructions. I will try it out.=C2=A0
BTW: your e= mail is very well-structured . Do you write your email in org-mode or some = other emacs mode which can recognize =C2=A0[C-h f function-name RET] and in= sert the results into the email?

Shiyuan=C2=A0

On Sun, Jun 22, 2014 at 1:20 AM, Thorsten J= olitz <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<= br> > 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-fl= eged
> 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=3Db
> \end{equation}
>
> #+BEGIN_SRC latex
>
> \begin{equation}
> \label{eq:test}
> Ax=3Db
> \end{equation}
> #+END_SRC

When you know how to write Emacs Lisp, you should probably defi= ne 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. =C2=A0PARENT is the name of | the parent back-end.
|
| BODY can start with pre-defined keyword arguments. =C2=A0The following | keywords are understood:
|
| =C2=A0 :export-block
|
| =C2=A0 =C2=A0 String, or list of strings, representing block names that | =C2=A0 =C2=A0 will not be parsed. =C2=A0This is used to specify blocks th= at will
| =C2=A0 =C2=A0 contain raw code specific to the back-end. =C2=A0These bloc= ks
| =C2=A0 =C2=A0 still have to be handled by the relative `export-block'= type
| =C2=A0 =C2=A0 translator.
|
| =C2=A0 :filters-alist
|
| =C2=A0 =C2=A0 Alist of filters that will overwrite or complete filters | =C2=A0 =C2=A0 defined in PARENT back-end. =C2=A0See `org-export-filters-a= list'
| =C2=A0 =C2=A0 for a list of allowed filters.
|
| =C2=A0 :menu-entry
|
| =C2=A0 =C2=A0 Menu entry for the export dispatcher. =C2=A0See
| =C2=A0 =C2=A0 `org-export-define-backend' for more information about = the
| =C2=A0 =C2=A0 expected value.
|
| =C2=A0 :options-alist
|
| =C2=A0 =C2=A0 Alist of back-end specific properties that will overwrite o= r
| =C2=A0 =C2=A0 complete those defined in PARENT back-end. =C2=A0Refer to | =C2=A0 =C2=A0 `org-export-options-alist' for more information about | =C2=A0 =C2=A0 structure of the values.
|
| =C2=A0 :translate-alist
|
| =C2=A0 =C2=A0 Alist of element and object types and transcoders that will=
| =C2=A0 =C2=A0 overwrite or complete transcode table from PARENT back-end.=
| =C2=A0 =C2=A0 Refer to `org-export-define-backend' for detailed infor= mation
| =C2=A0 =C2=A0 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:
|
| =C2=A0 (org-export-define-derived-backend 'my-latex 'latex
| =C2=A0 =C2=A0 =C2=A0:translate-alist '((template . my-latex-template-= fun)))
|
| The back-end could then be called with, for example:
|
| =C2=A0 (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)
|
|
| =C2=A0 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. =C2=A0DATA is an Org element, object, secondary | string or string. =C2=A0CONTENTS, when non-nil, is the transcoded
| contents of DATA element, as a string. =C2=A0INFO, 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 =C2=A0for property :language.

But maybe a simple filter could the work too and somebody with deeper
insights gives you better advice ...

--
cheers,
Thorsten



--001a113304ac47d02a04fc8eb58e--