GNU bug report logs - #79083
31.0.50; Inconsistencies wrt fixed-pitch face

Previous Next

To reply to this bug, email your comments to 79083 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Inconsistencies wrt fixed-pitch face
Date: Wed, 23 Jul 2025 15:27:14 +0100

X-debbugs-cc: eliz <at> gnu.org, yantar92 <at> posteo.net, bzg <at> gnu.org, prot <at> protesilaos.com

Hello,

There are a couple of related issues I would like to resolve with the
fixed-pitch face.

(1)
I had assumed that the purpose of this face was solely to be fixed pitch
even when the default face uses a variable pitch font.  A Lisp program
could use this face when something really must display as fixed pitch.

But in [1] Eli writes:
> Did you expect the fixed-pitch face to have the same font as the
> default face?  If so, it's a wrong expectation: we deliberately
> defined the fixed-pitch face to have a different typeface, so that it
> stands out.

This is not incompatible with being a face that's always fixed pitch no
matter whether the default face is fixed pitch, but it does mean that
themes, or the user, shouldn't usually customise default and fixed-pitch
to use the same typeface.  If this is the idea, then it should be
documented, and I would propose to do so as follows:

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/faces.el b/lisp/faces.el
index cf81013118b..ad5b467b9e2 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2463,7 +2463,11 @@ underline
 
 (defface fixed-pitch
   '((t :family "Monospace"))
-  "The basic fixed-pitch face."
+  "The basic fixed-pitch face.
+This face is intended to be visually distinct from the `default' face on
+graphical frames, even when the `default' face also uses a fixed-pitch
+typeface.  In practice this means that this face should always use a
+different typeface to the `default' face's typeface."
   :group 'basic-faces)
 
 (defface fixed-pitch-serif
--8<---------------cut here---------------end--------------->8---

(2)
The faces are not in fact visually distinct by default on GNU/Linux,
though they are on the non-free macOS and MS-Windows platforms.  This
should be fixed.  I am not sure where to look in the code base, though
-- the different typefaces for default and fixed-pitch on MS-Windows,
for example, aren't defined in faces.el, but presumably somewhere in C.
Could I have a hint?

[1]  https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg00396.html

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79083 <at> debbugs.gnu.org, bzg <at> gnu.org, yantar92 <at> posteo.net,
 prot <at> protesilaos.com
Subject: Re: bug#79083: 31.0.50; Inconsistencies wrt fixed-pitch face
Date: Wed, 23 Jul 2025 19:45:19 +0300

> Cc: eliz <at> gnu.org, yantar92 <at> posteo.net, bzg <at> gnu.org, prot <at> protesilaos.com
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Wed, 23 Jul 2025 15:27:14 +0100
> 
> (1)
> I had assumed that the purpose of this face was solely to be fixed pitch
> even when the default face uses a variable pitch font.  A Lisp program
> could use this face when something really must display as fixed pitch.
> 
> But in [1] Eli writes:
> > Did you expect the fixed-pitch face to have the same font as the
> > default face?  If so, it's a wrong expectation: we deliberately
> > defined the fixed-pitch face to have a different typeface, so that it
> > stands out.
> 
> This is not incompatible with being a face that's always fixed pitch no
> matter whether the default face is fixed pitch, but it does mean that
> themes, or the user, shouldn't usually customise default and fixed-pitch
> to use the same typeface.  If this is the idea, then it should be
> documented, and I would propose to do so as follows:

Sorry, I object to codifying this kind of stuff.  Faces exist in Emacs
so that users and distros could change them however they wish.  If
they want fixed-pitch to look the same as the default face, they
should be free to do that.  If the result is not to their liking
(which is in the eyes of the beholder), they will see it soon enough
and decide then what they want to do with it.

The mere fact that there is a separate face is already a clear sign
that we _recommend_ it to look differently.  There should be no reason
to say anything beyond that.

> (2)
> The faces are not in fact visually distinct by default on GNU/Linux,

It depends on the font back-end, AFAIK.  Only some of them use the
Monospace family for the default face's font, see
x_default_font_parameter.

> though they are on the non-free macOS and MS-Windows platforms.  This
> should be fixed.

Not sure about the "should" part.  Do people think the typeface used
for symbols in Info manuals looks sub-optimally on GNU/Linux, and
would like it to look differently?  If enough users think that, we
could try a different definition.  But there be dragons: to change
that we need to modify the font family for the default face so that it
is different from the family of the fixed-pitch face, and such changes
might be met with resistance by some parts of the community.  That is
why I suggest that we consider this carefully and thoroughly.  In
general, I'd let these sleeping dogs lie.

> I am not sure where to look in the code base, though
> -- the different typefaces for default and fixed-pitch on MS-Windows,
> for example, aren't defined in faces.el, but presumably somewhere in C.

It's in faces.el, see face-font-family-alternatives.  And it isn't
Windows specific, contrary to what you thought ;-)

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

From: Protesilaos Stavrou <prot <at> protesilaos.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79083 <at> debbugs.gnu.org, bzg <at> gnu.org, eliz <at> gnu.org, yantar92 <at> posteo.net
Subject: Re: bug#79083: 31.0.50; Inconsistencies wrt fixed-pitch face
Date: Thu, 24 Jul 2025 09:48:32 +0300

On 2025-07-23 17:27, Sean Whitton wrote:
> X-debbugs-cc: eliz <at> gnu.org, yantar92 <at> posteo.net, bzg <at> gnu.org, 
> prot <at> protesilaos.com
> 
> Hello,

Hello Sean,

> [...]
> 
> This is not incompatible with being a face that's always fixed pitch no
> matter whether the default face is fixed pitch, but it does mean that
> themes, or the user, shouldn't usually customise default and 
> fixed-pitch
> to use the same typeface.  If this is the idea, then it should be
> documented, and I would propose to do so as follows:

I do not see a problem with 'default' and 'fixed-pitch' using the same 
font family if that is monospaced. Interfaces/users/themes that 
absolutely need to distinguish regular text from "monospaced" text, like 
Info, should rely on more than just the font family (e.g. the 
'Info-quoted' face can have a distinct foreground value).

Personally, I would never want 'fixed-pitch' to be a monospaced family 
other than my preferred one. Different fonts come with differing 
inherent metrics. Some fonts look taller/shorter than others even when 
they are set to the same ':height' value. If you force users to apply 
distinct fonts, then you must expect them to set 'fixed-pitch' to a 
':height' like '0.9' or '1.1'. This is inconvenient and dependent on the 
exact ':height' value of the 'default' face. The relative height needs 
to be adjusted when the default font is made smaller/larger, which makes 
'text-scale-adjust' awkward.

Another common problem with fonts of varying heights is how the text can 
appear to jump around when the user scrolls to a point that has a taller 
line. I remember dealing with this recently while 
'display-line-numbers-mode' was enabled.

> [...]
> 
>  (defface fixed-pitch
>    '((t :family "Monospace"))
> -  "The basic fixed-pitch face."
> +  "The basic fixed-pitch face.
> +This face is intended to be visually distinct from the `default' face 
> on
> +graphical frames, even when the `default' face also uses a fixed-pitch
> +typeface.  In practice this means that this face should always use a
> +different typeface to the `default' face's typeface."
>    :group 'basic-faces)

I would personally not follow this guideline. Yes, 'fixed-pitch' should 
be a monospaced font to be consistent with the expectations it sets. 
Other than that, the user can pick any font family they want.

All the best,
Protesilaos (or simply "Prot")

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79083 <at> debbugs.gnu.org, bzg <at> gnu.org, yantar92 <at> posteo.net,
 prot <at> protesilaos.com
Subject: Re: bug#79083: 31.0.50; Inconsistencies wrt fixed-pitch face
Date: Thu, 24 Jul 2025 08:47:17 +0100

Hello,

On Wed 23 Jul 2025 at 07:45pm +03, Eli Zaretskii wrote:

> Sorry, I object to codifying this kind of stuff.  Faces exist in Emacs
> so that users and distros could change them however they wish.  If
> they want fixed-pitch to look the same as the default face, they
> should be free to do that.  If the result is not to their liking
> (which is in the eyes of the beholder), they will see it soon enough
> and decide then what they want to do with it.
>
> The mere fact that there is a separate face is already a clear sign
> that we _recommend_ it to look differently.  There should be no reason
> to say anything beyond that.

It was not a clear sign at all for me, and it is highly unlikely that I
am the only one.  The only indication was a mailing list post from you.

I don't desire to codify it, only to write down this design idea in the
code or docs, so that it's included with Emacs, and more accessible than
mailing list posts.

Actually, I think "recommend", as you wrote, is stronger than necessary.
I just want to note somewhere that in the default look of Emacs, they're
meant to be visually distinguishable.  That's it.

I'll plan to add a simple comment next to the definition of fixed-pitch.

>> (2)
>> The faces are not in fact visually distinct by default on GNU/Linux,
>
> It depends on the font back-end, AFAIK.  Only some of them use the
> Monospace family for the default face's font, see
> x_default_font_parameter.
>
>> though they are on the non-free macOS and MS-Windows platforms.  This
>> should be fixed.
>
> Not sure about the "should" part.  Do people think the typeface used
> for symbols in Info manuals looks sub-optimally on GNU/Linux, and
> would like it to look differently?  If enough users think that, we
> could try a different definition.  But there be dragons: to change
> that we need to modify the font family for the default face so that it
> is different from the family of the fixed-pitch face, and such changes
> might be met with resistance by some parts of the community.  That is
> why I suggest that we consider this carefully and thoroughly.  In
> general, I'd let these sleeping dogs lie.
>
>> I am not sure where to look in the code base, though
>> -- the different typefaces for default and fixed-pitch on MS-Windows,
>> for example, aren't defined in faces.el, but presumably somewhere in C.
>
> It's in faces.el, see face-font-family-alternatives.  And it isn't
> Windows specific, contrary to what you thought ;-)

Thank you for the references.

Certainly the default face's font family on GNU/Linux should not change.
But possibly the fixed-pitch face's font family on GNU/Linux should
change, in order that it is actually distinct.

Based on what I've read this is my understanding:

- the default font family is selected by x_default_font_parameter.
  - on Windows this will yield Courier.
  - on GNU/Linux with Cairo, this is done by resolving the Cairo/Xft
    alias "monospace-10" to a concrete font family.

- the fixed-pitch font family is selected by resolving the "Monospace"
  Emacs font family alias according to face-font-family-alternatives:
  ("Monospace" "Cascadia Code" "Lucida Console" "courier" "fixed")
  - on Windows at least one of Cascadia Code and Lucida Console will be
    installed by default; on recent Windows you'll get Cascadia Code,
    which is visually distinct from Courier, as desired
  - on GNU/Linux chances are none of them are installed (I didn't even
    have Courier on my machine until just now) and so you'll get
    'fixed', which presumably is resolved concretely to the very same
    font family that "monospace-10" is resolved to.  Hence not visually
    distinct.

So I think the fix for the bug is to add some font families to
(assoc "Monospace" face-font-family-alternatives) which are both:
1. very commonly present on GNU/Linux installations; and yet
2. not what "monospace-10" will typically resolve to on those
   installations.

I don't know what font families would fit the bill, and I agree that it
should be considered carefully and thoroughly.  But is this a correct
statement of the structure of the problem?

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79083 <at> debbugs.gnu.org, bzg <at> gnu.org, yantar92 <at> posteo.net,
 prot <at> protesilaos.com
Subject: Re: bug#79083: 31.0.50; Inconsistencies wrt fixed-pitch face
Date: Thu, 24 Jul 2025 11:08:36 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 79083 <at> debbugs.gnu.org,  bzg <at> gnu.org,  yantar92 <at> posteo.net,
>   prot <at> protesilaos.com
> Date: Thu, 24 Jul 2025 08:47:17 +0100
> 
> > The mere fact that there is a separate face is already a clear sign
> > that we _recommend_ it to look differently.  There should be no reason
> > to say anything beyond that.
> 
> It was not a clear sign at all for me, and it is highly unlikely that I
> am the only one.  The only indication was a mailing list post from you.

Well, now you know.  I realize that not every aspect of the Emacs
design has its intent necessarily evident to everyone, but that
doesn't yet mean we should make changes based on the fact that it
takes time to understand the underlying ideas and their rationale.

> I don't desire to codify it, only to write down this design idea in the
> code or docs, so that it's included with Emacs, and more accessible than
> mailing list posts.
> 
> Actually, I think "recommend", as you wrote, is stronger than necessary.
> I just want to note somewhere that in the default look of Emacs, they're
> meant to be visually distinguishable.  That's it.

They are not "meant to be" distinguishable, we _think_ that it's a
good idea to make them so.  And Prot already posted his dissenting
views in this particular case.

> Certainly the default face's font family on GNU/Linux should not change.
> But possibly the fixed-pitch face's font family on GNU/Linux should
> change, in order that it is actually distinct.

But that would mean the definition of the fixed-pitch face will use
different families on GNU/Linux and on other platforms.  We want to
avoid that as much as possible.

>   - on GNU/Linux chances are none of them are installed (I didn't even
>     have Courier on my machine until just now) and so you'll get
>     'fixed', which presumably is resolved concretely to the very same
>     font family that "monospace-10" is resolved to.  Hence not visually
>     distinct.

No, on GNU/Linux we request "Monospace" from Fontconfig, and use what
it gives us.

> So I think the fix for the bug is to add some font families to
> (assoc "Monospace" face-font-family-alternatives) which are both:
> 1. very commonly present on GNU/Linux installations; and yet
> 2. not what "monospace-10" will typically resolve to on those
>    installations.

This will probably not fix the issue, because (as the comment there
says) face-font-family-alternatives is only used on systems without
Fontconfig, which basically means we ignore it on GNU/Linux.  We'd
need to make changes in Fontconfig files, something that I think is
not acceptable.

> I don't know what font families would fit the bill, and I agree that it
> should be considered carefully and thoroughly.

What you see in the current code _is_ the product of carefully
considering these issues, and also of many years of experience using
the results.  Personally, I wouldn't touch that with a 10-mile pole.

Again, would you please state some real-life problems we are trying to
fix here?

Previous Next

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