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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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