bug#56808: 29.0.50; Elusive display problem on macOS

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> Are there any :align-to display properties involved in this?
> ("C-x =" could help you find out.)

No, nothing there, no properties, no overlays.  Just spaces, AFAICT.

>   (gdb) pgrow
>
> This should display the glyph_row with some detail.
>
> Of course, you don't have GDB, so some of the above will need to be
> done differently, sigh...  In particular, the 'pgrow' command is
> defined in src/.gdbinit.

Yeah, no GDB fpr the old white man here :-/. Maybe I smatter something
in Python for LLDB if it turns out I can't find out what happens
without.

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.

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?

Anyways.  That are all not exactly being wild guesses, but as you can
see I'm still making "Bayesian" guesses.  In the hope of getting by
without debugging, which won't happen, I see that already coming :-).

Thanks!