From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: LaTex best practice in org-mode Date: Sun, 22 Jun 2014 10:20:34 +0200 Message-ID: <874mzdnynh.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wyd1J-0005IG-BN for emacs-orgmode@gnu.org; Sun, 22 Jun 2014 04:21:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wyd1B-0005Tb-RQ for emacs-orgmode@gnu.org; Sun, 22 Jun 2014 04:21:01 -0400 Received: from plane.gmane.org ([80.91.229.3]:48308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wyd1B-0005TQ-Hd for emacs-orgmode@gnu.org; Sun, 22 Jun 2014 04:20:53 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wyd15-0002ya-M8 for emacs-orgmode@gnu.org; Sun, 22 Jun 2014 10:20:47 +0200 Received: from g231234245.adsl.alicedsl.de ([92.231.234.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Jun 2014 10:20:47 +0200 Received: from tjolitz by g231234245.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Jun 2014 10:20:47 +0200 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: emacs-orgmode@gnu.org 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