New commit.
Answers inline,

On Sat, 3 Jan 2026 at 15:32, Ihor Radchenko <[email protected]> wrote:

> Pedro Andres Aranda Gutierrez <[email protected]> writes:
>
> > there are a couple more commits in the feature branch. Against my
> > judgement, but I have included the possibility of using main,sans and
> mono
> > everywhere. Once again, I don't like that at all, because it diverges
> from
> > the examples people can find in the Internet and that will be a source of
> > confusion.
>
> I think it is ok to leave LaTeX name in the main text in the manual but
> put a footnote that alternative name (tt / mono, etc) can be used
> interchangeably. WDYT?
>

Isn't this not clear enough?
>From the manual:
-----
2. ~:variant~ : a string for the font variant (e.g. ~"main"~ or ~"rm"~
   for the Serif font family, ~"sans"~ or ~"sf"~ for Sans Serif, and
   ~"mono"~ or ~"tt"~ for Monospace).  The four-letter version for the
   variant corresponds to the family used above for ~fontspec~.  It
   will be translated to
   [[https://en.wikibooks.org/wiki/LaTeX/Fonts][the two-letter codes
   used in LaTeX for the different font families]][fn::Reference
   sources in the Internet always use the two-letter code].  When no
   variant is indicated, it is assumed that the serif font family
   (variant ~"main"~ or ~"rm"~) is implied.  It is recommended that
   you always add the variant *explicitly*.
-----

>  That is done. I allow the default features to be a string of
> > comma-separated feature definitions. Internally, it also allows the
> default
> > features to be a list of strings, each with one feature definition. It
> > mimics the '+' in the default features definition.
>
> Thanks!
>
> One note about the code:
>
> > + (setq font-family (alist-get font-family org-latex--long2short-family
> font-family nil #'string=))
>

> This implies that *only* main/sans/mono/math will be allowed, but not
> tt/sf/rm. Looks like an omission.
>
If you try out the following in the scratch buffer:
```
(let ((font-family-alist '(("mono" . "tt")
                           ("sans" . "sf")
                           ("main" . "rm"))))
  (dolist (font-family '("mono" "sans" "main" "tt" "sf" "rm"))
    (message "%s -> %s" font-family (alist-get font-family
font-family-alist font-family nil #'string=))))
```
AND you read the docstring for alist-get (describe-function), you will
notice that I'm using font-family as the key (first parameter) and as the
default value (third parameter).
This means that when the key is not in the list, you get the key back.

>
>> What about
> >>
> >> (("main" :font "TeXGyreSchola"
> >>   :fallbacks (("AppleColorEmoji:mode=harf" :script "emoji")))
> >
> > They are not strictly the same,OK. But it is always the font family or
> the
> > missing script that trigger the use of a font.
> >
> > Your example in the current format
> >
> > (("main" :font "TeXGyreSchola"
> >   :fallbacks (("emoji" :font "AppleColorEmoji:mode=harf")))
> >
> > reads as:
> > For the 'main' font family use system font "Tex Gyre Schola" and,
> > if Emacs tells you that there are characters it identifies as "emoji",
> > use font "Apple Color Emoji", which needs to use the HarfBuzz renderer.
> > As I have already explained, it is always a
> > family/script -> font+optional config
> > mapping. It hardly can be more consistent.
>
> Ok. This looks good enough for me.
>
...

> > BTW, look at the new missing font parser in one of the last commits.
>
> One comment on the code:
>
> > +          ;; Sort the list by FONT
> > +          (sort font-script #'(lambda (s1 s2)
> > +                                (string< (car s1) (car s2))))
> > +          ;; Remove duplicates
> > +          (delete-dups font-script)
>
> You should use (setq (sort ...))


Sorry. I'm using something that has been there since Emacs25 in the form it
was originally defined...
Interestingly enough, when you add :in-place t explicitly, the compiler
warns about unused result.
Using the original form doesn't trigger any warnings in the byte-compiler,
so it can't be too wrong.

and (setq (delete-dups ..)).
>

No, describe-function delete-dups explicitly says that this is a
destructive delete and that the result
internally stored back to the list passed to the procedure. And here we are
talking about a procedure
introduced in Emacs 22 (please).


> Also, if we know the problematic characters, I am wondering if we can
> extract the logic from `describe-char-display' and suggest specific font
> to be used. (This is optional, but sounds fairly easy).
>

Let's leave this FFS. I don't think it is that easy and I doubt the gain is
worth the effort. You get much more from examples in the documentation.


> -
>
> And further comments on earlier commits:
>
> About :features / :props alias.
> Same comment about the manual as for the font familiar.
>
???

> Additionally, ox-latex code added :features as an alias to :props but
> not :props as an alias to :features. I think we should have both, so
> that people can use them interchangeably.
>

That was not what I have understood from your messages.
It will increase confusion, but anyhow...

About :fallback.
> One possible common need could be setting a fallback without changing
> the default font. Maybe we can give an example of that in the manual.
>
When you have to resort to a fallback, you must indicate the font family
you apply it to and that implies indicating the font used for that family.
The font is a mandatory parameter to the LaTeX command.

Or, alternatively, may we make :font option in
> `org-latex-polyglossia-font-config' optional and use the default font if
> it is not specified?
>
Again. this is NOT POSSIBLE, full stop.


> --
> 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

Reply via email to