Subject: bug#56393: Actually fix the long lines display bug

From: Eli Zaretskii <[email-masked]>
Date: Mon, 18 Jul 2022 20:04:54 +0300

> Date: Mon, 18 Jul 2022 16:21:27 +0000
> From: Gregory Heytings <[email-masked]>
> cc: [email-masked], [email-masked], [email-masked]
> 
> 
> By the way, one last optimization would be possible in get_narrowed_begv. 
> Is there a way to check (efficiently) whether the buffer is displayed with 
> a single font in a single size?

Not that I know of, no.  At least we don't keep this information
anywhere, even after we compute it for display.  In particular, if we
never displayed some part of the buffer since the beginning of the
session, we don't even know what fonts that could require.  And
computing that takes the same effort as displaying the text in the
first place.

But maybe I misunderstand the question: what do you mean by "buffer is
displayed"?  We never display the entire buffer, only as much as fits
in the window.  So do you really mean "the buffer" or "the portion of
the buffer visible in the window" (or something else)?

> Or IOW, whether the buffer is displayed in a "character-only
> terminal" way?

That translates into a lot of potential issues.  First, you need a
fixed-pitch default face, right?  Then you need to ensure we don't
have any characters that are displayed by fonts other than the default
face's font, either because these characters aren't supported by the
font, or required by some non-default face, or even because some face
requires the default font, but with a different weight or size or
slant.  You also need to make sure there are no overlays in the
buffer, and no 'display' or invisible properties.  Maybe also that
tab-width is at its default value?  Maybe there's more.