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