* Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`)
@ 2022-03-11 14:45 Denis Bitouzé
2022-03-11 19:38 ` Nick Dokos
0 siblings, 1 reply; 2+ messages in thread
From: Denis Bitouzé @ 2022-03-11 14:45 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`)
2022-03-11 14:45 Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`) Denis Bitouzé
@ 2022-03-11 19:38 ` Nick Dokos
0 siblings, 0 replies; 2+ messages in thread
From: Nick Dokos @ 2022-03-11 19:38 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-03-11 19:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-11 14:45 Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`) Denis Bitouzé
2022-03-11 19:38 ` Nick Dokos
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).