emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia


From: Juan Manuel Macías
Subject: Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Date: Fri, 15 Jul 2022 15:38:25 +0000

Max Nikulin writes:

> I would consider structures with named fields (alists or plists) for a
> case of adding some additional settings (Font name? But it is rather
> defcustom than defconst)
>
> ("es" . (:babel "spanishmx" :poliglossia "spanish"
> :poliglossia-variant "mexican")

I was paying more attention to the fontenc issue and I had forgotten to
comment this.

I think your proposal to use a property list makes sense. But I don't
quite see what new settings could be added without overcomplicating
things. Babel in its latest versions has several ways to load languages,
and many new commands to select fonts or associate font families to a
specific language or script. But they don't work with pdfLaTeX, so the
only thing I could think of is to keep the old babel method, valid for
all TeX engines, according to which, if a user puts in an org document:

#+language: es
#+latex_header: \usepackage[foo,AUTO]{babel}

it returns:

\usepackage[foo,spanish]{babel}

which is valid for all flavors of TeX. And I think that this way, as Org
was doing so far, it will satisfy most users.

But given the syntactical variety that babel now has (polyglossia is
simpler), I don't see how all of that could be 'translated' to Org via
Org settings. I think this is one of those cases where it's easier for
the user to just build the LaTeX preamble writing LaTeX code or create a
new 'class' for org-latex-classes. The problem with Org writing the
preamble for the user is that it will never satisfy all users. That is
why I think it is necessary for this 'automatic' preamble to be as basic
and elementary as possible (I, for example, always write the preamble
from scratch or write my own sty files). Otherwise we run the risk of
converting, or wanting to convert, Org into a clone of LaTeX, but less
flexible than LaTeX.

I agree that most Org users (like most Pandoc users) just want to
produce a clean pdf without messing with LaTeX. But if users want to do
more things in LaTeX, they should know some LaTeX, even if they prefer
to use a lightweight markup language as a latex 'interface'. That's why
I think it's great that in Org you can enter arbitrary LaTeX (or html)
code anywhere and at many levels. I think this is the real killer
feature of Org. I don't know if I'm explaining myself... But this
reflection of mine (which, of course, is debatable) would take us
further, and this is not the case here. 

Other than that, your idea of using a property list sounds good to me.
What happens is that I do not see a clear advantage (at least in the
short term).

Best regards,

Juan Manuel 



reply via email to

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