Hi,
On 15/10/26 21:04, Ihor Radchenko wrote:
"Pedro A. Aranda" <[email protected]> writes:
+ When the document metadata include the shorthand ~DOC_LANGS~, it
+ will be replaced by the main language declared with the ~LANGUAGE~
+ and ~OTHER_LANGUAGES~ keywords, formatted by
+ ~org-latex-build-doclangs-function~. This custom variable points
+ to either of the functions ~org-latex-doclang-full~ or
+ ~org-latex-doclang-short~, or a user-defined function:
...
+ language=en, other-languages={es, fr}}
...
+\DocumentMetadata{tagging=on, lang=en}
I feel that this is going in a wrong direction.
ACK, although not agreeing with it from my limited experience since
starting with ltx-talk.
I currently have three systems, each with a different texlive and its
capabilities, to test the range from "the latest and best" to "what we
currently have".
But is it something common for the users?
The purpose of defcustom is usually covering common user alternatives,
not extreme edge cases.
We already have huge number of customizations, and I believe that there
should be a limit to the amount of details to be customized.
Maybe you are right when talking about _one_ user doing his/her editing.
But just think about a group of users collaborating on a document. You
shouldn't impose a certain setup there. Just from my experience, in a
research environment, you may end up with 3 to 4 operating systems (even
more if you count OS versions) and each will have their own TeX.
The whole point of export backend is automating LaTeX export, so that
users do not need to customize every possible detail, conditioned on
exact details of the latex version used or the compiler.
If I have learnt something in this process, it is that different systems
need different settings, just an example: it is not the same to use
MacTeX 2025 and MacTeX 2026 in my mac (the same system) because they
provide different versions for most packages.
I agree. Ideally, it is ox-latex's job to handle these edge cases
without forcing users to learn all the fine details.
We cannot avoid exposing certain things, but not simple latex internals
formatting.
What you propose can be achieved much simpler - by supplying
#+LATEX_DOC_METADATA: tagging=on, lang=en
directly.
But then, you are repeating the language which you might be setting with
#+LANGUAGE, which is redundant. Or you might oversee that you have one
setting in LANGUAGE and a different setting in DOC_METADATA, which might
be weird (or wrong).
IMHO, if you have to keep track of the LaTeX versions, redundant
language is much easier than trying to juggle Elisp functions.
As I mentioned above, I view your case as rather edge cases you
encounter as package maintainer who *needs* to investigate multiple
LaTeX versions.
Could you see it, maybe, as a user who needs to juggle to and fro
between MacTeX versions because he has to maintain "legacy" documents in
parallel with new materials and is trying to cope with the challenge of
porting.
I'd rather write DOC_LANGS and profit from new features when on a newer
MacTeX and add a directory local variable to make sure that everyone
uses the same (it would be the 'older' of course) when collaborating.
The other alternative, i.e. imposing everyone to install a specific
TeXlive version for a project, is just impossible.
If you want to support different latex versions, we should automatically
detect it and use the appropriate format.
How? By running ~<latex_compiler> -version~ parsing that and then
setting the variable I propose (or something of the sorts) to produce
the correct output?
Yes, or using LaTeX machinery like \iftex for this purpose.
Or, if absolutely necessary, setting latex version in defcustom. That's
much more straightforward compared to adjusting very fine
latex-version-specific detail for a peculiar latex command. (And we may
possibly need to have more similar customizations, in which case the
users will have to change them all together)
... And what do we do when the interaction between babel
and DocumentMetadata is refined once again?
Could you elaborate?
If you look at how the LaTeX package "babel" is evolving to better
interwork with the document metadata, you'll understand.
PS: I'm also thinking about the FIXME regarding the conversion from Org
language to BCP language codes and where to place it. This gives us a
limited and well-identifiable set of functions to implement it.
What about org-latex-language-alist?
Yes, that's my main focus right now...
--
Pedro A. Aranda
ox-latex & ox-beamer maintainer
Sagen's Paradeiser! (ORF: Als Radiohören gefährlich war) => write BE!
IA: onomatopeya del rebuzno
2nd year of the New Koprocracy
