Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`)

Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`)

[Denis Bitouzé]

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:

--8<---------------cut here---------------start------------->8---
#+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!
--8<---------------cut here---------------end--------------->8---

For this, it is possible to redefine the `org-latex-code` function:

--8<---------------cut here---------------start------------->8---
;; 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)))
--8<---------------cut here---------------end--------------->8---

but, IMHO, this should be the default.

WDYT?
-- 
Denis

Re: Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`)

[Nick Dokos]

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