"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. >> 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. >> 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? > 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? -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
