Before I put more effort on this I'd need comments on the last batch of "fixes" I've pushed.
/PA On Sun, 30 Nov 2025 at 20:42, Pedro Andres Aranda Gutierrez < [email protected]> wrote: > Answers inline > Enviado desde mi iPad > > > El 30 nov 2025, a las 19:06, Ihor Radchenko <[email protected]> > escribió: > > > > Pedro Andres Aranda Gutierrez <[email protected]> writes: > > > >> Are we talking about everything or just about babel configuration? > > > > 1. Everything in terms of the way values are defined > Sorry for trying to provide flexibility… this seems to be the source of > most of your confusion. > > 2. Whether things should be consolidated to a single variable is not > > something I worry *too* much about > > > >> What is too complex in the following config for fontspec? > >> > >> ((org-mode > >> . ((org-latex-multi-lang . "fontspec") > >> (org-latex-fontspec-default-features > >> . (("Scale" . "MatchLowercase"))) > >> (org-latex-fontspec-config > >> . (("main" :font "TeXGyreSchola" > >> :fallback (("emoji" . "AppleColorEmoji:mode=harf"))) > >> ("sans" :font "TeXGyreHeros") > >> ("mono" :font "DejaVu Sans Mono" :features > "Scale=MatchLowercase) > >> ("math" :font "Stix Two Math")))))) > > > > 1. default-features is defined as list of cons, while fontspec features > > is a string while fallback font features is defined with font itself. > > All different! I find this confusing. > OK, we put everything as strings. > > 2. I am not a big fan of nesting :fallback. Some users tend to get lost > > in complex structures (me too). We had discussions with Emacs devs on > > this topic and the general suggestion is sticking to plists. Either > > directly in variables, or, at least, using some macro helpers to set > > complex variables. > In this case, we really need them. This allows us to grow as we go. > Go back to the MWE sent to the list by a user how wanted to add emojis. > > > >> Do you have an idea to make fallback configuration easier? > > > > ((org-mode > > . ((org-latex-multi-lang . "fontspec") > > (org-latex-fontspec-default-features . "Scale=MatchLowercase,...") > Again, OK, we use strings only, no problem > > (org-latex-fontspec-fonts > > . (("TeXGyreSchola" :family "main") > > ("AppleColorEmoji" :family "main" :onchar "emoji" :features > "mode=harf") > > ("TeXGyreHeros" :family "sans") > For me, fallbacks are subordinate fonts. Having a prop in the fonts that > marks the fallback fonts makes it easier to identify them in the LaTeX > export. I don’t identify them as easily with your proposal. Well, actually > I’m confused by this proposal. Honestly. > > > ("DejaVu Sans Mono" :family "mono" :features > "Scale=MatchLowercase") > > ("Stix Two Math" :family "math")))))) > These we already have. > > > >>> For other options, things like shorthands, babelhyphenation, digits, > etc. > >>> We do not really need to implement them now. :provide is enough. But > >>> others can be added if users ask for them. > >> > >> With this spirit, the fontspec part could have been added ages ago... > > > > extra parameters for babel will be much easier to add. > > > >>>> Yup, it is more appealing to me. Moreover, it has a potential to merge > >>>>> all font-related settings into a single customization. After all, > what > >>>>> are chances that you would need different fonts for the same language > >>>>> for babel vs. polyglossia? > >>>> > >>>> Contributions to conferences vs. book chapters, for example. Has > happened > >>>> to me. > >>> > >>> Could you elaborate? Your example is a documentclass. How does it have > >>> anything to do wrt babel vs. polyglossia? > >> > >> Of course I can. I have contributed to conferences and book chapters. > >> In some cases you don't need to do anything but use a document class > from > >> the submission, throughout the review and at the final submission of the > >> camera ready version of the paper for the proceedings and that is > heaven. > >> But I also came across situations where you were asked to include extra > >> customisations taking into account babel and then, when the paper was > going > >> to be included in a book, the book's publisher was using polyglossia and > >> they wanted you to use specific font configurations to get the > preprints, > >> etc. > > > > That sounds like something suitable as in-buffer option, file-local > > variable or directory-local. It is not like you *always* go for one font > > in polyglossia but other in babel. Or do I miss something? > > (Note that most users do not use directory-locals or file-locals) > > > >>> Imagine a single customization like `org-latex-fonts'. > >>> Users can then > >>> ;; For all compilers > >>> (push '("CMU Serif" :family "sf") org-latex-fonts) > >>> (push '("Noto Sans Mono" :family "tt") org-latex-fonts) > >>> ;; Just for babel > >>> (push '("Noto Serif" :family "sf" :package "babel") org-latex-fonts) > >>> ;; Just for ja + babel > >>> (push '("Noto CJK" :lang "ja" :family "rm" :package "babel") > >>> org-latex-fonts) > >>> > >> I can see why disagree completely... > >> Mainly I can relate better to configurations if I take the language as > the > >> base element for the configuration. > >> Because when reading the the LaTeX export, I check the #+LANGUAGE line > in > >> Org and start from there. > >> And then because I prefer to have separate configurations coexisting in > >> different variables. > >> If there is a problem and I say I want fontspec, I prefer to inspect > >> org-latex-fontspec-config directly than to skim through a variable which > >> mixes everything and potentially miss the point (for example the > languages > >> plist). > > > > Ok. I have no problem with keeping separate variables. > > What is more important for me is the format of values and making sure > > that there is no need to learn a brand new format for each polyglossia > > setting vs. babel setting vs. fontspec setting. > > > >> ... > >> I don't see myself writing that higher level layer, though. > > > > I will be willing to update your code once we decide about more uniform > > value format. I do find it really important. > > As new functions that sit on top and feed the variables we already have, > please. So people can decide on which format they want to use. > > > But I first want to make sure that we have no critical disagreement > > about what that format would be. > > > > -- > > 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> > -- Fragen sind nicht da, um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler "Sagen's Paradeiser" (ORF: Als Radiohören gefährlich war) => write BE! Year 1 of the New Koprocracy
