bug#22207: emacs-25 mishandles info code text on Fedora 23

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]

When I use emacs-25 to view the Elisp manual on Fedora 23 x86-64, Emacs 
mishandles the font for code: code is displayed in a considerably 
smaller font, making the manual harder to read and looking a bit like a 
ransom note. A sample is attached. I am using 'emacs -Q' to read the 
info file. If I view the same (i.e., the emacs-25) info file with Emacs 
24.5 as bundled with Fedora, the display looks fine, with the same 
fixed-width font used for all text.


In GNU Emacs 25.0.50.8 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.6)
  of 2015-12-17
Repository revision: 1b5630eb47d3f4bade09708c958ab006b83b3fc0
Windowing system distributor 'Fedora Project', version 11.0.11800000
Configured using:
  'configure --enable-gcc-warnings'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
   shell-dirtrack-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   buffer-read-only: t
   line-number-mode: t
   transient-mark-mode: t

Recent messages:
Checking 24 files in /home/eggert/src/gnu/emacs/my/lisp/cedet...
Checking 57 files in /home/eggert/src/gnu/emacs/my/lisp/calendar...
Checking 87 files in /home/eggert/src/gnu/emacs/my/lisp/calc...
Checking 122 files in /home/eggert/src/gnu/emacs/my/lisp/obsolete...
Checking for load-path shadows...done
You can run the command ‘report-emacs-bug’ with M-x r-em RET
Checking for load-path shadows...done
Auto-saving...done
Quit [3 times]
C-M-g is undefined

Load-path shadows:
None found.

Features:
(pp shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils help-fns help-mode cl-loaddefs pcase
cl-lib shell pcomplete comint ansi-color ring info easymenu time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 123742 15169)
  (symbols 48 19951 3)
  (miscs 40 89 292)
  (strings 32 23330 7050)
  (string-bytes 1 657185)
  (vectors 16 12693)
  (vector-slots 8 432940 13272)
  (floats 8 150 162)
  (intervals 56 4895 83)
  (buffers 976 16)
  (heap 1024 38893 944))


[-- Attachment #2: Screenshot from 2015-12-18 10-21-19.png --]
[-- Type: image/png, Size: 15715 bytes --]

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Glenn Morris]

Paul Eggert wrote:

> When I use emacs-25 to view the Elisp manual on Fedora 23 x86-64,
> Emacs mishandles the font for code: code is displayed in a
> considerably smaller font, making the manual harder to read and
> looking a bit like a ransom note. 

I guess this is the same issue as http://debbugs.gnu.org/19889
Info-quoted face specifies Courier font.
I still don't think it's a good idea.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 18 Dec 2015 13:57:36 -0500
> Cc: 22207@debbugs.gnu.org
> 
> Paul Eggert wrote:
> 
> > When I use emacs-25 to view the Elisp manual on Fedora 23 x86-64,
> > Emacs mishandles the font for code: code is displayed in a
> > considerably smaller font, making the manual harder to read and
> > looking a bit like a ransom note. 
> 
> I guess this is the same issue as http://debbugs.gnu.org/19889
> Info-quoted face specifies Courier font.
> I still don't think it's a good idea.

Yes, this is a deliberate feature.  Perhaps we should make it
dependent on a defcustom.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Glenn Morris]

Eli Zaretskii wrote:

>> Info-quoted face specifies Courier font.
>> I still don't think it's a good idea.
>
> Yes, this is a deliberate feature.  Perhaps we should make it
> dependent on a defcustom.

A face is a customizable object.
The issue is that the default is bad.
Emacs wants a monospace/typewriter style font.
"Sans mono" may be a better default, but I'm sure that will be wrong
sometimes too. Can Emacs do the equivalent of

fc-match "Monospace"

?

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  22207@debbugs.gnu.org
> Date: Fri, 18 Dec 2015 14:49:15 -0500
> 
> Eli Zaretskii wrote:
> 
> >> Info-quoted face specifies Courier font.
> >> I still don't think it's a good idea.
> >
> > Yes, this is a deliberate feature.  Perhaps we should make it
> > dependent on a defcustom.
> 
> A face is a customizable object.

How many Emacs users will know what change to make in a face to have
@code{} display like the normal text?

What I had in mind was a binary option telling Emacs whether to use a
distinct face for @code.  I think this is way easier to customize than
a face's font.

> Emacs wants a monospace/typewriter style font.
> "Sans mono" may be a better default, but I'm sure that will be wrong
> sometimes too. Can Emacs do the equivalent of
> 
> fc-match "Monospace"

How will that help?  Someone, somewhere will still dislike the result.

But yes, Emacs can do this: call x-family-fonts with no arguments, and
then filter the returned list to retain only those fonts whose FIXED-P
element is t.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Wolfgang Jenkner]

On Fri, Dec 18 2015, Eli Zaretskii wrote:

>> fc-match "Monospace"
>
> How will that help?  Someone, somewhere will still dislike the result.

Mono(space) is a fontconfig alias, it's explicitly selected in
a configuration file[*] and users are supposed to override it if they don't
like it.

[*] http://cgit.freedesktop.org/fontconfig/tree/conf.d/60-latin.conf

(Often, fonts install their own font config files which override the
default configuration).

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Wolfgang Jenkner <wjenkner@inode.at>
> Cc: Glenn Morris <rgm@gnu.org>,  eggert@cs.ucla.edu,  22207@debbugs.gnu.org
> Date: Sat, 19 Dec 2015 15:21:10 +0100
> 
> On Fri, Dec 18 2015, Eli Zaretskii wrote:
> 
> >> fc-match "Monospace"
> >
> > How will that help?  Someone, somewhere will still dislike the result.
> 
> Mono(space) is a fontconfig alias, it's explicitly selected in
> a configuration file[*] and users are supposed to override it if they don't
> like it.

That means an even more complex mess: suppose Emacs will use some
fixed-pitch font from that alias, and the user doesn't like it -- now
the user will have to be familiar not only with font specs for
customizing faces, but also with the fontconfig customizations and
configuration files.  Doesn't strike me as a particularly
user-friendly feature.

Once again, I suggest a single binary defcustom that could be used to
disable use of a special face for code typeface.  We could (and
probably should) tell in NEWS how to get back the old behavior by
customizing that variable.  This is by far simpler than silently
assuming users will futz with their font setups.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Wolfgang Jenkner]

On Sat, Dec 19 2015, Eli Zaretskii wrote:

>> >> fc-match "Monospace"
>> >
>> > How will that help?  Someone, somewhere will still dislike the result.
>> 
>> Mono(space) is a fontconfig alias, it's explicitly selected in
>> a configuration file[*] and users are supposed to override it if they don't
>> like it.
>
> That means an even more complex mess: suppose Emacs will use some
> fixed-pitch font from that alias, and the user doesn't like it -- now
> the user will have to be familiar not only with font specs for
> customizing faces, but also with the fontconfig customizations and
> configuration files.  Doesn't strike me as a particularly
> user-friendly feature.

fc-match returns a single match.  Also, emacs does know about fontconfig
aliases (info "(emacs) Fonts").  The problem is that specifying an alias
name as the family attribute doesn't always work as expected (because
emacs font selection weighs font attributes in a different way).

For example, on my system

$ fc-match Serif
NotoSerif-Regular.ttf: "Noto Serif" "Regular"
$ 

However, if I customize the Info-quoted face replacing "courier" by
"Serif" I get

xft:-unknown-Sawasdee-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1

Not a big problem, but just to elaborate a bit on Glenn's suggestion.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Wolfgang Jenkner]

On Sat, Dec 19 2015, Wolfgang Jenkner wrote:

> The problem is that specifying an alias
> name as the family attribute doesn't always work as expected (because
> emacs font selection weighs font attributes in a different way).

My parenthetical remark above about font attribute weights may be
misleading as I haven't actually investigated the situation.

> However, if I customize the Info-quoted face replacing "courier" by
> "Serif" I get

> xft:-unknown-Sawasdee-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1

While specifying "Noto Serif" instead works as expected.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Wolfgang Jenkner <wjenkner@inode.at>
> Cc: eggert@cs.ucla.edu,  22207@debbugs.gnu.org
> Date: Sat, 19 Dec 2015 16:28:19 +0100
> 
> On Sat, Dec 19 2015, Eli Zaretskii wrote:
> 
> >> >> fc-match "Monospace"
> >> >
> >> > How will that help?  Someone, somewhere will still dislike the result.
> >> 
> >> Mono(space) is a fontconfig alias, it's explicitly selected in
> >> a configuration file[*] and users are supposed to override it if they don't
> >> like it.
> >
> > That means an even more complex mess: suppose Emacs will use some
> > fixed-pitch font from that alias, and the user doesn't like it -- now
> > the user will have to be familiar not only with font specs for
> > customizing faces, but also with the fontconfig customizations and
> > configuration files.  Doesn't strike me as a particularly
> > user-friendly feature.
> 
> fc-match returns a single match.

You can use the --all switch to countermand that, AFAIK.

> Also, emacs does know about fontconfig aliases (info "(emacs) Fonts").

Doesn't this mean that your comments about fontconfig customizations
are not relevant to the issue at hand?  AFAIU, Glenn mentioned
fc-match as a way to explain what he meant, he didn't really mean
Emacs to run that command.  If Emacs cannot use its output, then its
configuration by users will never affect us.

And we are back to the original issue: suppose Emacs does run the
_equivalent_ of the above (I mentioned one way of doing it in Emacs):
is there any doubt that someone somewhere will find the results not to
her liking and would like to see the Info-quote face identical to the
rest of the text in an Info buffer?  If so, then trying to use a
fixed-pitch font, even if it's other than Courier, will never succeed
to be a "one size fits all" solution.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Glenn Morris]

Glenn Morris wrote:

> fc-match "Monospace"

Actually I see Emacs has a font called fixed-width that does exactly that.
So my simple suggestion for fixing this issue:

  Info-quoted and tex-verbatim face should inherit from fixed-width by default.

(The fact that that specification of fixed-width doesn't appear to work
on either Debian or Red Hat seems a separate issue! Ie, it gives a face
that looks exactly like the default face. "Sans Mono" works for me.
Still, I don't recally anyone ever complaining about the fixed-width face.)

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  22207@debbugs.gnu.org
> Date: Sat, 19 Dec 2015 14:16:19 -0500
> 
> Actually I see Emacs has a font called fixed-width that does exactly that.
> So my simple suggestion for fixing this issue:
> 
>   Info-quoted and tex-verbatim face should inherit from fixed-width by default.
> 
> (The fact that that specification of fixed-width doesn't appear to work
> on either Debian or Red Hat seems a separate issue! Ie, it gives a face
> that looks exactly like the default face.

Probably because the default font is a fixed-pitch font, no?  IOW,
wouldn't this be a no-op on all platforms?

> "Sans Mono" works for me.

Where "works" means what?

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Date: Sat, 19 Dec 2015 21:21:32 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, 22207@debbugs.gnu.org
> 
> > From: Glenn Morris <rgm@gnu.org>
> > Cc: eggert@cs.ucla.edu,  22207@debbugs.gnu.org
> > Date: Sat, 19 Dec 2015 14:16:19 -0500
> > 
> > Actually I see Emacs has a font called fixed-width that does exactly that.

Do you mean the fixed-pitch _face_?  I don't think I see the
fixed-width font.

> > So my simple suggestion for fixing this issue:
> > 
> >   Info-quoted and tex-verbatim face should inherit from fixed-width by default.

Here you mean a face, not a font, and again I don't see any face named
fixed-width.  What am I missing?

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Glenn Morris]

(Typo, I meant "fixed-pitch".)

Eli Zaretskii wrote:

> Probably because the default font is a fixed-pitch font, no?  IOW,
> wouldn't this be a no-op on all platforms?

Durh, probably, yes. Silly me.

>> "Sans Mono" works for me.
>
> Where "works" means what?

Gives a face that looks different from the default in "the right way"
for a "typewriter" face. The default face is "DejaVu Sans Mono",
"Sans Mono" selects "Latin Modern Mono". This all sounds like a massive
fluke now that I look at the details.

Anyway, as Stefan suggested, there should be some single face that
Info-quoted and tex-verbatim inherit from. What the defaults of that face
should be are another issue. Inherit from string face?

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  22207@debbugs.gnu.org
> Date: Sat, 19 Dec 2015 14:31:14 -0500
> 
> 
> (Typo, I meant "fixed-pitch".)

OK, in that case, this face is not like the default one on my system.
Its only attribute that is not "unspecified" is the "font family",
which is "Monospace".  I think this is what you wanted.

The Info-quoted face has its font family set to "courier", but at
least here it uses exactly the same font as fixed-pitch.

So I'm unsure how using fixed-pitch or inheriting from it would solve
the problem.  It is slightly cleaner, in that there's a single parent
face, but I guess Paul will still be unhappy with the results.

> Gives a face that looks different from the default in "the right way"
> for a "typewriter" face. The default face is "DejaVu Sans Mono",
> "Sans Mono" selects "Latin Modern Mono". This all sounds like a massive
> fluke now that I look at the details.

So on some systems the fixed-pitch face will be nicer than the current
Info-quoted, on others it will be the same, and perhaps on still
others it will be uglier.

> Inherit from string face?

You mean, font-lock-string-face?

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Glenn Morris]

Eli Zaretskii wrote:

>> Inherit from string face?
>
> You mean, font-lock-string-face?

Yes.
Anyway, I think I am just muddying the waters, so will shut up.
See the merged bug for Stefan's ideas.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  22207@debbugs.gnu.org
> Date: Sat, 19 Dec 2015 22:40:56 -0500
> 
> Eli Zaretskii wrote:
> 
> >> Inherit from string face?
> >
> > You mean, font-lock-string-face?
> 
> Yes.
> Anyway, I think I am just muddying the waters, so will shut up.
> See the merged bug for Stefan's ideas.

Let's start with fixed-pitch -- Paul, does that display OK on that
Fedora 23 system?  Glenn, does that display differently from the
default font on yours?

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

Eli Zaretskii wrote:
> Let's start with fixed-pitch -- Paul, does that display OK on that
> Fedora 23 system?

Sorry, I don't know what you're asking me to try here. Can you give me some 
Elisp code to evaluate? I can try it the next time I'm at my Fedora 23 workstation.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Cc: 22207@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 20 Dec 2015 13:14:35 -0800
> 
> Eli Zaretskii wrote:
> > Let's start with fixed-pitch -- Paul, does that display OK on that
> > Fedora 23 system?
> 
> Sorry, I don't know what you're asking me to try here. Can you give me some 
> Elisp code to evaluate? I can try it the next time I'm at my Fedora 23 workstation.

In "emacs -Q", evaluate this in *scratch* (before loading Info):

  (defface Info-quoted
    '((t :family "Monospace"))
    "Face used for quoted elements.")

then type "C-u C-h i" to read some manual where you previously didn't
like how code text looks, and see if it now looks better.

Thanks.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

[Following up on an old bug report that I mislaid]:

On 12/21/2015 08:18 AM, Eli Zaretskii wrote:
> In "emacs -Q", evaluate this in*scratch*  (before loading Info):
>
>    (defface Info-quoted
>      '((t :family "Monospace"))
>      "Face used for quoted elements.")
>
> then type "C-u C-h i" to read some manual where you previously didn't
> like how code text looks, and see if it now looks better.

It looks different, but still not good. Now, the code text looks exactly 
like the non-code text, which is less informative. I'm attaching a 
screenshot of the same text as before.


[-- Attachment #2: Screenshot from 2016-02-12 17-22-38.png --]
[-- Type: image/png, Size: 16041 bytes --]

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Cc: rgm@gnu.org, 22207@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 12 Feb 2016 17:29:07 -0800
> 
> On 12/21/2015 08:18 AM, Eli Zaretskii wrote:
> > In "emacs -Q", evaluate this in*scratch*  (before loading Info):
> >
> >    (defface Info-quoted
> >      '((t :family "Monospace"))
> >      "Face used for quoted elements.")
> >
> > then type "C-u C-h i" to read some manual where you previously didn't
> > like how code text looks, and see if it now looks better.
> 
> It looks different, but still not good. Now, the code text looks exactly 
> like the non-code text, which is less informative. I'm attaching a 
> screenshot of the same text as before.

But if your default font is already monospaced, what would you expect
from Info-quoted face to produce?  I thought the result which you
describe is exactly what was wanted in this case.  IIRC, we had that
before the change that introduced this face.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

Eli Zaretskii wrote:
> if your default font is already monospaced, what would you expect
> from Info-quoted face to produce?  I thought the result which you
> describe is exactly what was wanted in this case.  IIRC, we had that
> before the change that introduced this face.

Sorry, you're right; I forgot about the old behavior.

Ideally code would be in a different monospaced font, one that is readable. 
Perhaps a bolder font, say. So the change was an improvement in that it uses a 
different monospaced font, but it's a disimprovement in that the different font 
is irritatingly small.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

I just now attempted to reproduce this bug on emacs-25, and could not 
reproduce it; the display looks OK (see attached). Although I am still 
running Fedora 23 x86-64, I have installed several packages since the 
original bug report in December so it's possible that the problem has 
gone away because some new fonts have been installed. Another 
possibility is that the bug has been fixed in draft Emacs 25 somehow. 
Either way, I will close this particular bug report now as I can't 
reproduce it.


[-- Attachment #2: Screenshot-from-2016-05-05-13-45-22.png --]
[-- Type: image/png, Size: 15295 bytes --]

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Glenn Morris]

Paul Eggert wrote:

> I just now attempted to reproduce this bug on emacs-25, and could not
> reproduce it; the display looks OK (see attached). Although I am still
> running Fedora 23 x86-64, I have installed several packages since the
> original bug report in December so it's possible that the problem has
> gone away because some new fonts have been installed. Another
> possibility is that the bug has been fixed in draft Emacs 25 somehow.
> Either way, I will close this particular bug report now as I can't
> reproduce it.

Nothing's changed in Emacs, and Info-quoted and tex-verbatim faces
continue to look poor on RHEL 7, so I unmerged and reopened my own
#19889.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

[Redirecting from Bug#22207]

On 05/05/2016 02:29 PM, Glenn Morris wrote:
> Info-quoted and tex-verbatim faces
> continue to look poor on RHEL 7, so I unmerged and reopened my own
> #19889.
>
Please try the attached patch against Emacs 25. It attempts to implement 
Stefan's suggestions in Bug#19889, and this improved things for me on 
Fedora 23, when I ran 'emacs -Q'.

Although this patch makes things worse when I run emacs without -Q, that 
is because I have this in my ~/.Xresources:

Emacs.font: -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1

which is an old-timer expert setting that I should really fix one of 
these days, so I wouldn't put too much weight on my glitch.


[-- Attachment #2: 0001-Improve-display-of-tex-verbatim.patch --]
[-- Type: application/x-patch, Size: 4286 bytes --]

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 05 May 2016 17:29:20 -0400
> Cc: eggert@cs.ucla.edu
> 
> Paul Eggert wrote:
> 
> > I just now attempted to reproduce this bug on emacs-25, and could not
> > reproduce it; the display looks OK (see attached). Although I am still
> > running Fedora 23 x86-64, I have installed several packages since the
> > original bug report in December so it's possible that the problem has
> > gone away because some new fonts have been installed. Another
> > possibility is that the bug has been fixed in draft Emacs 25 somehow.
> > Either way, I will close this particular bug report now as I can't
> > reproduce it.
> 
> Nothing's changed in Emacs, and Info-quoted and tex-verbatim faces
> continue to look poor on RHEL 7, so I unmerged and reopened my own
> #19889.

Is what you see similar to what's shown on the image attached to
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19889#15?  If so, can you
explain what is your problem with that display?  It looks fine to me,
but maybe I'm missing something.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 5 May 2016 15:54:39 -0700
> 
> On 05/05/2016 02:29 PM, Glenn Morris wrote:
> > Info-quoted and tex-verbatim faces
> > continue to look poor on RHEL 7, so I unmerged and reopened my own
> > #19889.
> >
> Please try the attached patch against Emacs 25. It attempts to implement 
> Stefan's suggestions in Bug#19889, and this improved things for me on 
> Fedora 23, when I ran 'emacs -Q'.
> 
> Although this patch makes things worse when I run emacs without -Q, that 
> is because I have this in my ~/.Xresources:
> 
> Emacs.font: -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1
> 
> which is an old-timer expert setting that I should really fix one of 
> these days, so I wouldn't put too much weight on my glitch.

If we are going to use such kludges, why not specify fonts explicitly
in the defface to begin with?  After all, that's what your patch
attempts to do, albeit indirectly, right?

In general, I find the family specification to be too fragile for any
reliable specification of typefaces: the results are inconsistent
across different systems and tend to depend too much on local setup.
Unfortunately, we don't have a font expert on board who could point
out how to do that better, or how to improve the current font
selection machinery to produce more reliable results.  (My impression
is that all the font-related attributes are not perceived as mandatory
enough, and the font selection code tries very hard to find _some_
font, even if it doesn't fit the constraints.  But I have no proof for
this impression.)

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Glenn Morris]

Eli Zaretskii wrote:

> In general, I find the family specification to be too fragile for any
> reliable specification of typefaces: the results are inconsistent
> across different systems and tend to depend too much on local setup.

That was exactly the point of my report.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  19889@debbugs.gnu.org
> Date: Fri, 06 May 2016 11:47:58 -0400
> 
> Eli Zaretskii wrote:
> 
> > In general, I find the family specification to be too fragile for any
> > reliable specification of typefaces: the results are inconsistent
> > across different systems and tend to depend too much on local setup.
> 
> That was exactly the point of my report.

OK, but you seemed also to complain about the results in your
particular case, which (according to the image you posted) I find
satisfactory: we asked for a monospaced font and got a monospaced
font, which looks different from the default one.  So if there's any
problem with that image, can you point it out?

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

On 05/05/2016 11:49 PM, Eli Zaretskii wrote:
> If we are going to use such kludges, why not specify fonts explicitly
> in the defface to begin with?  After all, that's what your patch
> attempts to do, albeit indirectly, right?

The patch I proposed basically implements the suggestions Stefan made in 
<http://bugs.gnu.org/19889#6> and <http://bugs.gnu.org/19889#24>. Stefan 
was responding to Glenn’s original bug report, which suggests that it is 
not a good idea for a face definition to specify a font explicitly, due 
to portability problems on systems lacking the font. See the attachment 
to <https://bugzilla.redhat.com/684797> for an example of how verbatim 
text in TeX mode was displayed as little black boxes because TeX mode 
specifies an explicit font on a platform lacking it.

I am by no means an expert on Emacs fonts or on font technology in 
general. That being said, I would like to fix this blocking bug, and 
Stefan’s suggestion was the only concrete one on the table. If the patch 
is problematic, then is there a better way to fix this bug? More 
specifically: is it the introduction of ‘fixed-pitch-serif’ that you’re 
objecting to, or the addition of FreeMono and Nimbus Mono L as fonts to 
look for, or is it something else? Is there some way we could make the 
patch less kludgy, while still addressing Glenn’s and Stefan’s concerns?

bug#19889: tex-verbatim face: don't specify :family?

[Glenn Morris]

Eli Zaretskii wrote:

> Is what you see similar to what's shown on the image attached to
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19889#15?  If so, can you
> explain what is your problem with that display? 

That face looks poor compared to all the others.
If you don't agree with me, fine, please just close this as wontfix,
since I've said everything I can possibly say on this subject already
and it doesn't seem to bother others.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

On 05/06/2016 08:58 AM, Eli Zaretskii wrote:
> if there's any
> problem with that image, can you point it out?

Here is my reaction to Glenn’s attachment to 
<http://bugs.gnu.org/19889#15>. Some users are reaaaaally annoyed by 
aliased (“jagged”) fonts, particularly when combined with text that is 
mostly anti-aliased. The annoyance level can depend on the display 
technology: due to subpixel rendering, for example, what you see when 
you look at Glenn’s attachment on your display may differ from what 
Glenn sees on his display.

Other users aren’t bothered at all.

With all this in mind, I can sympathize with Glenn’s discomfort with his 
attachment: although on my display it is sort of OK (certainly better 
than I observed in my attachment to <http://bugs.gnu.org/22207#1>), the 
serifed text is distractingly blocky.

Plus, there’s another problem with Emacs’s current approach: on my 
Fedora 23 platform, the jagged font lacks serifs, which defeats the main 
point of specifying Courier for quoted Info text.

The combination of these two issues makes the Emacs manual look more 
amateurish on my platform. In contrast, the anti-aliased font is 
smoother and fits in better. Although many users will not care about the 
difference, some will. I’ll attach screenshots to try to illustrate.

Although I think this bug should be fixed, the patch’s improvement is 
small enough that I do not see the bug as a blocker against Emacs 25.


[-- Attachment #2: without-patch.png --]
[-- Type: image/png, Size: 15240 bytes --]

[-- Attachment #3: with-patch.png --]
[-- Type: image/png, Size: 17395 bytes --]

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Cc: 19889@debbugs.gnu.org, Stefan Monnier <monnier@IRO.UMontreal.CA>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 6 May 2016 09:24:11 -0700
> 
> Here is my reaction to Glenn’s attachment to 
> <http://bugs.gnu.org/19889#15>. Some users are reaaaaally annoyed by 
> aliased (“jagged”) fonts, particularly when combined with text that is 
> mostly anti-aliased. The annoyance level can depend on the display 
> technology: due to subpixel rendering, for example, what you see when 
> you look at Glenn’s attachment on your display may differ from what 
> Glenn sees on his display.
> 
> Other users aren’t bothered at all.

I guess I belong to the latter group.  I see the difference, but I'm
not bothered by it.  What matters is that the font should be
monospaced; beyond that, we have very little to expect.

> Plus, there’s another problem with Emacs’s current approach: on my 
> Fedora 23 platform, the jagged font lacks serifs, which defeats the main 
> point of specifying Courier for quoted Info text.

AFAIU, the main point of specifying that face was to have a face
different from default that is still monospaced.  And both fonts
satisfy that condition, so I don't see any further problems we should
care about.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Cc: rgm@gnu.org, 19889@debbugs.gnu.org,
>  Stefan Monnier <monnier@IRO.UMontreal.CA>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 6 May 2016 08:59:48 -0700
> 
> I am by no means an expert on Emacs fonts or on font technology in 
> general. That being said, I would like to fix this blocking bug, and 
> Stefan’s suggestion was the only concrete one on the table. If the patch 
> is problematic, then is there a better way to fix this bug?

We could specify the font explicitly.

> More specifically: is it the introduction of ‘fixed-pitch-serif’
> that you’re objecting to, or the addition of FreeMono and Nimbus
> Mono L as fonts to look for

The latter.  I see that as a (perhaps complicated and a bit
unreliable) way of specifying a font which we know we want to get as
result.  If so, why not specify the font explicitly?

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

On 05/06/2016 10:18 AM, Eli Zaretskii wrote:
> We could specify the font explicitly.
>
>> >More specifically: is it the introduction of ‘fixed-pitch-serif’
>> >that you’re objecting to, or the addition of FreeMono and Nimbus
>> >Mono L as fonts to look for
> The latter.  I see that as a (perhaps complicated and a bit
> unreliable) way of specifying a font which we know we want to get as
> result.  If so, why not specify the font explicitly?

The problem is, which font to specify explicitly? Not all platforms have 
a font named "Courier". Mine doesn't (Fedora 23). If we knew that all 
Emacs platforms had an appropriate font (Courier, or FreeMono, or Nimbus 
Mono L, or whatever), we could specify that font, but I do not know of 
any such font, nor do I know how to query arbitrary platforms for such a 
font.

In further testing on my Fedora 23 host I discovered another suitable 
anti-aliased font, Courier 10 Pitch. It is also a free font and looks a 
bit better with emacs -Q, and Wikipedia says Courier 10 Pitch BT is the 
default Courier font on many GNU/Linux hosts 
<https://en.wikipedia.org/wiki/Courier_%28typeface%29#Courier_10_Pitch_BT>. 
So I will update my proposed patch to prefer Courier 10 Pitch to the 
alternatives already in the list.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Cc: rgm@gnu.org, 19889@debbugs.gnu.org, monnier@IRO.UMontreal.CA
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 6 May 2016 11:24:14 -0700
> 
> On 05/06/2016 10:18 AM, Eli Zaretskii wrote:
> > We could specify the font explicitly.
> >
> >> >More specifically: is it the introduction of ‘fixed-pitch-serif’
> >> >that you’re objecting to, or the addition of FreeMono and Nimbus
> >> >Mono L as fonts to look for
> > The latter.  I see that as a (perhaps complicated and a bit
> > unreliable) way of specifying a font which we know we want to get as
> > result.  If so, why not specify the font explicitly?
> 
> The problem is, which font to specify explicitly? Not all platforms have 
> a font named "Courier". Mine doesn't (Fedora 23). If we knew that all 
> Emacs platforms had an appropriate font (Courier, or FreeMono, or Nimbus 
> Mono L, or whatever), we could specify that font, but I do not know of 
> any such font, nor do I know how to query arbitrary platforms for such a 
> font.

I'm aware of the issue, but I very much doubt there are too many
variants out there.  We could enumerate them all, and try one after
another, or even do it specifically for each platform.  Which is more
or less what your patch does, isn't it?

> In further testing on my Fedora 23 host I discovered another suitable 
> anti-aliased font, Courier 10 Pitch.

So why do you say above you don't have Courier?

> It is also a free font and looks a bit better with emacs -Q, and
> Wikipedia says Courier 10 Pitch BT is the default Courier font on
> many GNU/Linux hosts
> <https://en.wikipedia.org/wiki/Courier_%28typeface%29#Courier_10_Pitch_BT>.
> So I will update my proposed patch to prefer Courier 10 Pitch to the
> alternatives already in the list.

We could systematically review the most popular platforms (how many
are there, anyway?), and simply state a font or a couple of them for
each platform.  And I won't be surprised if all of them mostly use the
same fonts, even if some of them aren't necessarily present sometimes.

IOW, I prefer naming fonts rather than asking for them via families.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Stefan Monnier]

> The problem is, which font to specify explicitly? Not all platforms
> have a font named "Courier".

That's what face-font-family-alternatives is for.  We already have an
entry in there for "courier", so it just needs to be completed.


        Stefan

bug#19889:

[Glenn Morris]

Paul Eggert wrote:

> Please try the attached patch against Emacs 25. It attempts to
> implement Stefan's suggestions in Bug#19889, and this improved things
> for me on Fedora 23, when I ran 'emacs -Q'.

Thanks, but it makes no difference for me on RHEL7.
Emacs still uses the same poor non-xft font:

 x:-adobe-courier-medium-r-normal--14-140-75-75-m-90-iso8859-1 

(The addition of fixed-pitch-serif as a base face is of course desirable.)

bug#19889:

[Glenn Morris]

PS Manually setting the font family to "Nimbus Mono L" works.
This is what fc-match returns for me:

  fc-match courier
  n022003l.pfb: "Nimbus Mono L" "Regular"

Yet for "font family: courier", Emacs selects x:-adobe-courier-medium,
for some reason.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

On 05/06/2016 12:01 PM, Eli Zaretskii wrote:
> I very much doubt there are too many
> variants out there.  We could enumerate them all, and try one after
> another, or even do it specifically for each platform.  Which is more
> or less what your patch does, isn't it?

Yes, that's why I want to install the patch. :-)

>> In further testing on my Fedora 23 host I discovered another suitable 
>> anti-aliased font, Courier 10 Pitch.
> So why do you say above you don't have Courier?

Because I don't have it exactly. The font on Fedora 23 is called "Courier 10
Pitch", not "Courier". It's from Bitstream and is quite close but not identical
to honest-to-goodness IBM Courier.

I just now checked another desktop, running Ubuntu 16.04, and it has the same
set of suitable fonts as Fedora 23. (It also has a Thai font that would suffice
for ASCII but this is probably not a good choice in general.)

> We could systematically review the most popular platforms (how many
> are there, anyway?), and simply state a font or a couple of them for
> each platform.  And I won't be surprised if all of them mostly use the
> same fonts, even if some of them aren't necessarily present sometimes.
>
> IOW, I prefer naming fonts rather than asking for them via families.

The problem with Courier is that there are so many fonts that are all so similar
to Courier and most people can't tell the difference. This is partly due to the
intellectual history behind Courier.

I looked for a good source about this issue, and found someone who took a
circa-2012 census of Courier-like fonts on various web browsers and who
evaluated their looks when combined with non-Courier fonts. He writes that on
GNU/Linux platforms, the most common Courier fonts were Nimbus Mono L (98.2%)
and FreeMono (85.2%) but these fonts are a bit faint to be mixing with other
fonts, and that Courier 10 Pitch (85.0%) was a better choice. On OS X, he writes
that Courier Std (2.1%), Consolas (48.6%), and Courier (99.5%) are all good
choices, whereas Courier New (96.8%) is a bit faint. On MS-Windows, he says
Consolas (88.6%) and Courier (3.6%) are good choices, whereas FreeMono (0.6%)
and Courier New (99.8%) are a bit faint. As a result of all this, he suggests
the following order for Web use: "Courier 10 Pitch", "Courier Std", Consolas,
Courier, "TeX Gyre Cursor", TeXGyreCursor, "Nimbus Mono L", FreeMono,
"Courier New", monospace. See
<http://www.grputland.com/2012/08/font-stacks-that-look-similar-in.html#cour20120806>.

I doubt whether GNU Emacs should be defaulting to the non-free fonts in that
list(e.g., Consolas), given that the free fonts are so widely available.Courier
New is often disliked (it was digitized directly from the IBM Selectric golfball
which was at odds with how the Selectric actually worked). I don't know about
TeX Gyre Cursor, but it doesn't seem to be common on Fedora and Ubuntu anyway.
The other Courier-like fonts are close to the list I already proposed.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rgm@gnu.org,  19889@debbugs.gnu.org
> Date: Fri, 06 May 2016 15:32:43 -0400
> 
> > The problem is, which font to specify explicitly? Not all platforms
> > have a font named "Courier".
> 
> That's what face-font-family-alternatives is for.  We already have an
> entry in there for "courier", so it just needs to be completed.

But if what we want is a specific font, then adding its family will
produce unreliable results, and might well yield a font we don't want
in some setups.

IOW, what you suggest was already tried, and found to fail in some
cases.  We are trying to fix those cases, so using the same technique
we already know is faulty sounds unwise to me.

bug#19889:

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 06 May 2016 16:22:53 -0400
> Cc: 19889@debbugs.gnu.org
> 
> PS Manually setting the font family to "Nimbus Mono L" works.
> This is what fc-match returns for me:
> 
>   fc-match courier
>   n022003l.pfb: "Nimbus Mono L" "Regular"
> 
> Yet for "font family: courier", Emacs selects x:-adobe-courier-medium,
> for some reason.

Both belong to the Courier family, right?  So which one is found first
is entirely implementation-dependent.

When we ask for a family, we are saying that we will accept _any_
member of that family.  If we are unwilling to accept some of its
members, we should request a specific font (or maybe specify more than
just a family, but I'm not aware of any such additional specs;
foundry, perhaps?).

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: rgm@gnu.org, 19889@debbugs.gnu.org, monnier@IRO.UMontreal.CA
> Date: Fri, 6 May 2016 20:03:09 -0700
> 
> I looked for a good source about this issue, and found someone who took a
> circa-2012 census of Courier-like fonts on various web browsers and who
> evaluated their looks when combined with non-Courier fonts. He writes that on
> GNU/Linux platforms, the most common Courier fonts were Nimbus Mono L (98.2%)
> and FreeMono (85.2%) but these fonts are a bit faint to be mixing with other
> fonts, and that Courier 10 Pitch (85.0%) was a better choice. On OS X, he writes
> that Courier Std (2.1%), Consolas (48.6%), and Courier (99.5%) are all good
> choices, whereas Courier New (96.8%) is a bit faint. On MS-Windows, he says
> Consolas (88.6%) and Courier (3.6%) are good choices, whereas FreeMono (0.6%)
> and Courier New (99.8%) are a bit faint. As a result of all this, he suggests
> the following order for Web use: "Courier 10 Pitch", "Courier Std", Consolas,
> Courier, "TeX Gyre Cursor", TeXGyreCursor, "Nimbus Mono L", FreeMono,
> "Courier New", monospace. See
> <http://www.grputland.com/2012/08/font-stacks-that-look-similar-in.html#cour20120806>.
> 
> I doubt whether GNU Emacs should be defaulting to the non-free fonts in that
> list(e.g., Consolas), given that the free fonts are so widely available.Courier
> New is often disliked (it was digitized directly from the IBM Selectric golfball
> which was at odds with how the Selectric actually worked). I don't know about
> TeX Gyre Cursor, but it doesn't seem to be common on Fedora and Ubuntu anyway.
> The other Courier-like fonts are close to the list I already proposed.

Courier New is the default font on MS-Windows, so selecting it means
we will have a face that is indistinguishable from the default: not
good.

Consolas comes with latest Windows versions out of the box, so I don't
think there's a problem in having it on the list (we could do that
only on Windows, if we don't want to recommend it on GNU/Linux).

I don't understand what "monospace" means in that list.  There's no
such font, AFAIK, and all the other fonts are monospaced already, so
what's behind that "monospace"? any other monospaced font?

Other than that, how about using the outcome of that census, and
request specific fonts it mentions, ordered by their quality, as the
census recommends?  I think this will yield better results than
relying on family matches.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

Glenn Morris wrote:

> Thanks, but it makes no difference for me on RHEL7.
> Emacs still uses the same poor non-xft font:
> 
>  x:-adobe-courier-medium-r-normal--14-140-75-75-m-90-iso8859-1 
> 
> (The addition of fixed-pitch-serif as a base face is of course desirable.)

Thanks for checking. I reproduced your problem on Ubuntu 16.04 by installing the
optional package xfonts-75dpi. Please try the attached patch to emacs-25 instead
of what I sent earlier. This patch tries to address Eli's comments, which I'll
follow up on separately.

[-- Attachment #2: 0001-Improve-display-of-tex-verbatim-and-Info-quoted.patch --]
[-- Type: text/x-diff, Size: 5072 bytes --]

From e17028f4319ba6f6979fd4f5003e3f55b138e8d2 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 7 May 2016 09:50:59 -0700
Subject: [PATCH] Improve display of tex-verbatim and Info quoted

Problem reported by Glenn Morris (Bug#19889).
* doc/emacs/display.texi (Standard Faces):
* doc/lispref/display.texi (Basic Faces):
* etc/NEWS: Mention fixed-pitch-serif.
* lisp/faces.el (face-font-family-alternatives):
New family alias Monospace Serif.
(fixed-pitch-serif): New face, which uses the new family.
* lisp/info.el (Info-quoted):
* lisp/textmodes/tex-mode.el (tex-verbatim): Use the new face.
---
 doc/emacs/display.texi     |  3 +++
 doc/lispref/display.texi   |  1 +
 etc/NEWS                   |  4 ++++
 lisp/faces.el              | 29 +++++++++++++++++++++++++++++
 lisp/info.el               |  2 +-
 lisp/textmodes/tex-mode.el |  3 +--
 6 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/doc/emacs/display.texi b/doc/emacs/display.texi
index 8039291..83be85f3 100644
--- a/doc/emacs/display.texi
+++ b/doc/emacs/display.texi
@@ -613,6 +613,9 @@ Standard Faces
 This face forces use of a fixed-width font.  It's reasonable to
 customize this face to use a different fixed-width font, if you like,
 but you should not make it a variable-width font.
+@item fixed-pitch-serif
+This face is like @code{fixed-pitch}, except the font has serifs and
+looks more like traditional typewriting.
 @cindex variable-pitch face
 @item variable-pitch
 This face forces use of a variable-width font.
diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
index 181bff0..087d6ba 100644
--- a/doc/lispref/display.texi
+++ b/doc/lispref/display.texi
@@ -3017,6 +3017,7 @@ Basic Faces
 @itemx bold-italic
 @itemx underline
 @itemx fixed-pitch
+@itemx fixed-pitch-serif
 @itemx variable-pitch
 These have the attributes indicated by their names (e.g., @code{bold}
 has a bold @code{:weight} attribute), with all other attributes
diff --git a/etc/NEWS b/etc/NEWS
index 785d14b..242d3fc 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1761,6 +1761,10 @@ calculation.  This function is different from 'window-body-width' in
 that it accounts for (i) continuation glyphs, (ii) the size of the
 font, and (iii) the specified window.
 
++++
+*** New basic face 'fixed-pitch-serif', for a fixed-width font with serifs.
+The Info-quoted and tex-verbatim faces now default to inheriting from it.
+
 ---
 ** New utilities in subr-x.el:
 
diff --git a/lisp/faces.el b/lisp/faces.el
index fddc036..b1ea0f0 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -98,7 +98,31 @@ face-font-selection-order
 (defcustom face-font-family-alternatives
   (mapcar (lambda (arg) (mapcar 'purecopy arg))
   '(("Monospace" "courier" "fixed")
+
+    ;; Monospace Serif is an Emacs invention, intended to work around
+    ;; portability problems when using Courier.  It should work well
+    ;; when combined with Monospaced and with other standard fonts.
+    ("Monospace Serif"
+
+     ;; This looks good on GNU/Linux.
+     "Courier 10 Pitch"
+     ;; This looks good on MS-Windows and OS X.
+     "Consolas"
+     ;; This looks good on OS X.  "Courier" looks good too, but is
+     ;; jagged on GNU/Linux and so is listed later as "courier".
+     "Courier Std"
+     ;; Although these are anti-aliased, they are a bit faint compared
+     ;; to the above.
+     "FreeMono" "Nimbus Mono L"
+     ;; These are aliased and look jagged.
+     "courier" "fixed"
+     ;; Omit Courier New, as it is the default MS-Windows font and so
+     ;; would look no different, and is pretty faint on other platforms.
+     )
+
+    ;; This is present for backward compatibility.
     ("courier" "CMU Typewriter Text" "fixed")
+
     ("Sans Serif" "helv" "helvetica" "arial" "fixed")
     ("helv" "helvetica" "arial" "fixed")))
   "Alist of alternative font family names.
@@ -2280,6 +2304,11 @@ fixed-pitch
   "The basic fixed-pitch face."
   :group 'basic-faces)
 
+(defface fixed-pitch-serif
+  '((t :family "Monospace Serif"))
+  "The basic fixed-pitch face with serifs."
+  :group 'basic-faces)
+
 (defface variable-pitch
   '((((type w32))
      ;; This is a kludgy workaround for an issue discussed in
diff --git a/lisp/info.el b/lisp/info.el
index 6426cfc..ae46fba 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -4236,7 +4236,7 @@ Info-mode-syntax-table
   "Syntax table used in `Info-mode'.")
 
 (defface Info-quoted
-  '((t :family "courier"))
+  '((t :inherit fixed-pitch-serif))
   "Face used for quoted elements.")
 
 (defvar Info-mode-font-lock-keywords
diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
index 3ac68bd..8545a09 100644
--- a/lisp/textmodes/tex-mode.el
+++ b/lisp/textmodes/tex-mode.el
@@ -801,8 +801,7 @@ 'tex-math-face
 (defvar tex-math-face 'tex-math)
 
 (defface tex-verbatim
-  ;; '((t :inherit font-lock-string-face))
-  '((t :family "courier"))
+  '((t :inherit fixed-pitch-serif))
   "Face used to highlight TeX verbatim environments."
   :group 'tex)
 (define-obsolete-face-alias 'tex-verbatim-face 'tex-verbatim "22.1")
-- 
2.7.4

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

Eli Zaretskii wrote:

> Courier New is the default font on MS-Windows, so selecting it means
> we will have a face that is indistinguishable from the default: not
> good.

OK, the patch I just sent to Bug#19889 does that.

> Consolas comes with latest Windows versions out of the box, so I don't
> think there's a problem in having it on the list (we could do that
> only on Windows, if we don't want to recommend it on GNU/Linux).

Probably not worth the hassle. I merely listed it after Courier 10 Pitch.

> I don't understand what "monospace" means in that list.  There's no
> such font, AFAIK, and all the other fonts are monospaced already, so
> what's behind that "monospace"? any other monospaced font?

The source was talking about CSS, and I guess "monospace" has a meaning in CSS
that is roughly the same as "Monospace" in face-font-family-alternatives.

> Other than that, how about using the outcome of that census, and
> request specific fonts it mentions, ordered by their quality, as the
> census recommends?  I think this will yield better results than
> relying on family matches.

The patch I just sent does that, by inventing a name "Monospace Serif" as a way
to make the request conveniently as an argument to :family when using defface.
It sounds like you may prefer doing this sort of thing in some other way, but I
do not know what that way would be and so would appreciate any advice, as I am
by no means an expert in Emacs font configuration and am just trying to get the
bug fixed for the typical user.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Cc: rgm@gnu.org, 19889@debbugs.gnu.org, monnier@IRO.UMontreal.CA
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 7 May 2016 10:05:27 -0700
> 
> > Other than that, how about using the outcome of that census, and
> > request specific fonts it mentions, ordered by their quality, as the
> > census recommends?  I think this will yield better results than
> > relying on family matches.
> 
> The patch I just sent does that, by inventing a name "Monospace Serif" as a way
> to make the request conveniently as an argument to :family when using defface.
> It sounds like you may prefer doing this sort of thing in some other way

No, what your patch does is fine with me, actually.  It does call out
font names, which is what I had in mind.

The result on my system is to use Consolas where Emacs previously used
Courier, to display symbols in Info buffers.  I don't mind the change,
but I'd urge others to try the patch and see if it causes any
problems.

> I am by no means an expert in Emacs font configuration

No one is these days, unfortunately.

Thanks.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

Eli Zaretskii wrote:
> I don't mind the change,
> but I'd urge others to try the patch and see if it causes any
> problems.

Yes, it's Glenn in particular that I had in mind. If this patch works for Glenn
I'm inclined to install it into the emacs-25 branch (which will encourage others
to test it too...).

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

On 05/07/2016 10:27 AM, Eli Zaretskii wrote:
> I don't mind the change,
> but I'd urge others to try the patch and see if it causes any
> problems.

I installed the patch into master, to get the ball rolling on that.

Although I had been thinking of installing the patch into emacs-25, I 
see that Bug#19759 no longer lists 19889 or 22207 as blockers, which 
means emacs-25 is not a suitable place for the patch. (Bug#22207 was a 
blocker but I could not reproduce it and so closed it on May 5.)

Bug#19889 says it blocks 19759 as of 2015-12-18 and there is no 
indication it was ever unblocked. Conversely, Bug#19759 does not 
currently list Bug#19889 as a blocker; I don't know why not. If 
Bug#19889 is supposed to still be a blocker, then the patch should be 
backported from master to emacs-25.

At any event Bug#19889 seems to be fixed in master, so I am boldly 
closing it now; if this is wrong we can always reopen it of course.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Cc: rgm@gnu.org, 19889-done@debbugs.gnu.org, monnier@IRO.UMontreal.CA
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 13 May 2016 14:33:17 -0700
> 
> Bug#19889 says it blocks 19759 as of 2015-12-18 and there is no 
> indication it was ever unblocked. Conversely, Bug#19759 does not 
> currently list Bug#19889 as a blocker; I don't know why not.

Perhaps this happened when 19889 was unmerged from all the other bug
reports.

I don't know if it should be a blocker: does the problem still exist
on emacs-25, and if so, is it bad enough to block the release?

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

Eli Zaretskii wrote:
> does the problem still exist
> on emacs-25,

Yes.

> is it bad enough to block the release?

Not from what I can see. On my screen it's a relatively minor issue (i.e., an
ugly font, but still readable).

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> Cc: rgm@gnu.org, 19889@debbugs.gnu.org, monnier@IRO.UMontreal.CA
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 14 May 2016 01:24:11 -0700
> 
> Eli Zaretskii wrote:
> > does the problem still exist
> > on emacs-25,
> 
> Yes.
> 
> > is it bad enough to block the release?
> 
> Not from what I can see. On my screen it's a relatively minor issue (i.e., an
> ugly font, but still readable).

Then I think we can leave the fix on master.  (I tried on my system,
and the font is also readable, and not even ugly IMO -- but it's a
different font from what you see, of course.)

Thanks.