From: Thorsten Jolitz <tjolitz@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: LaTex best practice in org-mode
Date: Tue, 24 Jun 2014 10:52:21 +0200 [thread overview]
Message-ID: <87vbrqn0ze.fsf@gmail.com> (raw)
In-Reply-To: CAOm4EMsrFR7BvFyOzaqS-hnThefL34KgbxsZtU2imWv0twe0xA@mail.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
prev parent reply other threads:[~2014-06-24 8:52 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
2014-06-24 8:52 ` Thorsten Jolitz [this message]
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=87vbrqn0ze.fsf@gmail.com \
--to=tjolitz@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).