bug#61196: 30.0.50; X11 rendering of horizontal line in log-edit mode fails with some fonts

[Eli Zaretskii <eliz@gnu.org>]

> From: Dima Kogan <dima@secretsauce.net>
> Date: Tue, 31 Jan 2023 00:29:39 -0800
> 
> Hi. I'm using a bleeding-edge build of emacs from git, but this
> particular issue I've been seeing for maybe 6 months now, or maybe even
> a year.
> 
> I'm using a GTK build of Emacs running on X11 on GNU/Linux. Some of that
> is significant.
> 
> I can tickle the bug by selecting a particular font, entering
> log-edit-mode, and entering some text:
> 
>   rm /tmp/xxx;
> 
>   emacs -Q -geometry 40x8 \
>     --eval "(progn (setf (alist-get 'font default-frame-alist) \"-adobe-courier-medium-r-*-*-12-*-*-*-*-*-iso8859-*\")
>       (require 'log-edit)
>       (find-file \"/tmp/xxx\")
>       (log-edit-mode)
>       (insert \"a:b\\n\\nc d\"))"
> 
> The result looks like the attached 12.png. Note the unrendered 000A
> character block. This is a bug. It should be rendering a horizontal line
> instead. And if I select a different font, it does work. I can do that
> by changing the "-12-" in the above command to "-22-". The result is
> attached in 22.png.
> 
> I see it in the wild all the time when making version control commits in
> emacs, and typing the commit message.

Looks like some subtle issue with font selection.  Can you bisect?
Initial investigation seems to indicate that this started happening
sometime in last August, but I could be mistaken, as what I see here
is not exactly what you see (I don't have that font installed).

In general, this is what happens in Emacs when some face fails to find
a suitable font for a GUI frame.  Then we fall back to the "glyphless"
display method.