bug#56808: 29.0.50; Elusive display problem on macOS

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

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

Alas, I managed to kill the Emacs instance yesterday with a C-c in the
terminal window instead of typing that into Emacs, so I can't check
right now.  I'm using lldb from the terminal because I don't know
dap-mode good enough yet.

I think the spaces showed the font I expected with C-u C-x =.  That's
only a string though, and XLFD which macOS certainly doesn't use, so I
don't know how far I should trust that.

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

Yes, I remember the face realization and so on.  With the usual
disclaimer--in its original form.

> Btw, 'pgrow' shows the face ID as well, so it
> can tell.

Yeah, rub it in ;-).

I guess I'll take a break.  Maybe I can insert some asserts somewhere to
make the whole thing more reproducible.  One idea might be that the font
used by a font-lock face (for :type) must be the same as the font of the
default face (the face for the spaces).

Hm, I have a custom-set-faces in the init.el...

 '(default ((t (:family "Monaco" :weight light :height 120))))

Hm....

Later.