bug#56808: 29.0.50; Elusive display problem on macOS

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 56808@debbugs.gnu.org
> Date: Thu, 28 Jul 2022 09:37:23 +0200
> 
> My current kind of working hypothesis is that this is caused by
> something in the "font department".  When the problem is there, Emacs
> seems to behave completely consistently, assuming that it has the wrong
> value for the width of a space.
> 
> For example, cursor movement in the wrongly displayed line, which should
> be using the current glyph row.  The cursor movement is entirely okay,
> when a space were a bit wider than normal.  From which I "conjecture"
> that the width of the space in the glyph row is already wrong.

If it's a font issue, "C-u C-x =" with the cursor on the space that is
larger than normal could help by showing the font used for that space.

> But then again, since the display of the run of spaces should be done as
> a string of characters in the same face, I also "conjecture" that the
> font of the face should be wrong.  Which I find sort of strange.
> Shouldn't then all characters have the wrong size, and things would
> align again?

If Emacs decided, for some reason, to use a different font for some
character, it will generate a separate face for it, and that face is
not exposed to Lisp.  (Normally, this only happens for non-ASCII
characters, though.)  Btw, 'pgrow' shows the face ID as well, so it
can tell.