GNU bug report logs - #59347
29.0.50; `:family` face setting ignored

Previous Next

Full log

Message #284 received at 59347 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 59347 <at> debbugs.gnu.org
Subject: Re: bug#59347: 29.0.50; `:family` face setting ignored
Date: Thu, 08 Dec 2022 09:12:38 -0500

> Do you mean that if a user chooses a font for the default face that has
> a single variant (say 'regular'), then the 'bold' face (which does not
> specify any family) should be realized with another font which has a bold
> variant?

Yes.

> And that the 'italic' face should likewise be realized with
> another font which has an italic variant?

Exactly.

> FWIW, I don't think either of these options are reasonable.

I can see reasons why some users would consider it not just reasonable
but "The Right Thing" in their specific situation.  The argument would
be as simple as "Which part of `bold` don't you understand?" and would
fundamentally be just the same as the argument that we should not use
a monospace font when the "sans-serif" family is specified.

> Why not.  But it is already possible to fine-tune each individual face with
> the existing mechanisms, so I'm not sure the added complexity is worth
> the price.

I'm not sure either, but I think the current discussion around
`variable-pitch` is similarly influenced by the fact that that we
specified the `:family` (and on top of that the face is called
"variable-pitch"), so it's obvious (to us human) that the desired result
should not be a monospace font.

IOW the context of this discussion implies a bias towards putting more
precedence on `:family` but we could restart this discussion replacing
"variable-pitch" with "bold" and "family" with "weight" and most of the
arguments would hold just as well, just favoring `:weight` this time
around :-(

In any case, I do support inclusion of your patch on the `emacs-29`
branch as "the best solution so far".


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.