bug#34476: fluffy whitespace in the mode-line, despite it running off the screen

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org
> Date: Tue, 29 Dec 2020 04:54:42 +0100
> 
> I've now gone ahead and polished up this a bit (and introduced the
> `long' setting, too).  After using it for a while, I see the obvious
> thing that `format-mode-line' does wrong -- it discards all text
> properties?  So I'll open a new bug report for that, and I'm closing
> this bug report.

Hmm... does the test below really work reliably on GUI frames?

> +      if (EQ (Vmode_line_compact, Qlong)
> +         && window_body_width (XWINDOW (selected_window), false) >=
> +         SCHARS (mode_string))
> +       {
> +         /* The window is wide enough; just display the mode line we
> +            just computed. */
> +         display_string (NULL, mode_string, Qnil,
> +                         0, 0, &it, 0, 0, 0,
> +                         STRING_MULTIBYTE (mode_string));

You are comparing the number of characters with the window-body width,
but the latter is measured in units of the frame's canonical character
width, i.e. the average width of the default face's font.  If someone
modifies the mode-line face to use a font of a different size, or even
has enough wide characters there to violate the "1 character = 1
column" assumption, that test will produce either truncated mode-line
string or will unnecessarily squeeze spaces from it.

I understand the difficulty of doing TRT, but perhaps we should at
least document this limitation, so that users don't expect too much
from this feature, and we don't get bug reports that will be hard to
fix?