emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippe


From: Nick Dokos
Subject: Re: Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`)
Date: Fri, 11 Mar 2022 14:38:06 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Hi Denis,

Denis Bitouzé <denis.bitouze@univ-littoral.fr> writes:

> Hi,
>
> here is a feature request about the LaTeX export (another one: the
> previous mine, https://list.orgmode.org/87zgmda67z.fsf@example.com/,
> sadly didn't get any answer).
>
> With `(setq org-latex-listings t)`, `src_⟨language⟩{⟨code snippet⟩}` is
> exported from `org-mode` to `LaTeX` into
> `\lstinline[language=⟨language⟩]~⟨code snippet⟩~` (here, `~` could be
> almost any token): so far, so good.
>
> But one could expect to get the same export with the usual `org-mode`
> syntax for code snippets: `~⟨code snippet⟩~` (this supposes the ⟨language⟩
> to be declared globally), as in the following example:
>
> #+OPTIONS:   toc:nil title:nil
>
> #+LaTeX_HEADER: \usepackage{xcolor}
> #+LaTeX_HEADER: \usepackage{listings}
> #+LaTeX_HEADER: 
> \lstset{language=[auto]lisp,basicstyle=\ttfamily,keywordstyle=\color{red}}
>
> #+PROPERTY: header-args :padline no :exports both :noweb yes :eval always
>
> src_lisp{defun} is fun!
>
> ~defun~ is fun!
>
>
> For this, it is possible to redefine the `org-latex-code` function:
>
> ;; Inspired by https://emacs.stackexchange.com/q/70720/5267
> (defun org-latex-code (code _contents info)
>   "Transcode a CODE object from Org to LaTeX.
> CONTENTS is nil.  INFO is a plist used as a communication
> channel."
>   (format "\\lstinline+%s+"
>           (org-element-property :value code)))
>
> but, IMHO, this should be the default.
>
> WDYT?

I have no opinion on whether it should be the default or not, but I
wanted to point out a possibility that might have not occurred to you:
it is possible to define what's called a "derived" exporter, an
exporter that shares most of its code with the exporter that it is
derived from and only overrides one or two functions where you need a
change.

See the doc string of the function `org-export-define-derived-backend'
for some details.  There are also many examples where this feature is
used (a simple one is in the doc string itself), but there are
examples in the Org mode code itself, e.g the beamer exporter
(ox-beamer.el) is derived from the LaTex one (ox-latex.el), as is the
koma-letter exporter (ox-koma-letter.el), and the markdown exporter
(ox-md.el) is derived from the HTML exporter in ox-html.el.

Deriving a new back end from the LaTeX exporter and redefining one or
two functions (like `org-latex-code' above) is IMO the best way
forward. You get an exporter that works as you want and the defaults
are left as-is (developers are wary about changing defaults: that
brings out a lot of complaints of the "it was working fine yesterday
but you broke it" variety). And you can publish your derived mode on
e.g Gitlab/Github/whatever and make it available in MELPA for others
to try out.

HTH.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler




reply via email to

[Prev in Thread] Current Thread [Next in Thread]