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

Previous Next

Full log

View this message in rfc822 format

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