[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master d014a5e: Use fixed-pitch font for display-line-numbers

From: Eli Zaretskii
Subject: Re: master d014a5e: Use fixed-pitch font for display-line-numbers
Date: Sat, 15 Jul 2017 10:08:09 +0300

> From: Alex <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Fri, 14 Jul 2017 18:09:43 -0600
> What about just removing Consolas from the "Monospace Serif" list,
> since it's the only sans-serif font in that list? That would make
> things a bit more consistent. It would mean that Windows would
> default to courier though, so maybe it's not worth it.

Yes, Courier looks ugly on Windows.  Moreover, the entire Monospace
Serif family was invented to fix a problem with displaying
tex-verbatim and Info-quoted faces (see bug#19889), which are quite
important to us.  Fixing that minor annoyance wasn't simple, and it
was done just a year ago, so I wouldn't rush to make changes in this
quite fragile setup.  (Note that the faces using this family must be
different from default, where they are used for tex-verbatim and
Info-quoted.  Also note that Consolas is also for macOS.)  It's
probably a good idea to add a comment there saying that Consolas is
sans-serif, though.

> > I have now reverted the change which prompted this sub-thread; I hope
> > that will make everyone (except James, perhaps ;-) happier, and we can
> > put this issue to rest.
> Thanks, that's good to hear. However, it is a bit disappointing that
> there's no easy way to specify a face that uses the default face if it's
> monospaced, and otherwise falls back to a font that is.

Maybe there is, it's just that I couldn't think of one.  Maybe the
problem that led me to try to use something other than default is not
a grave one, and doesn't require an out-of-the-box solution; we should
wait and see.

> Alternatively, what about using fixed-pitch-serif for line-number on
> Windows, and fixed-pitch on other platforms?

Only if necessary, as platform-specific defaults should be avoided as
much as possible.  (There's also the NS case, where I'm not sure what

reply via email to

[Prev in Thread] Current Thread [Next in Thread]