bug#52183: 29.0.50; Empty space in the mode line if server-mode is active

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dm@mssdvd.com,  52183@debbugs.gnu.org
> Date: Sat, 04 Dec 2021 23:01:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The main point of what I wrote is that we actually display the whole
> > 5-to-6 character sequence of indicators as 4 separate strings, not as
> > a single string made of concatenation of those 4.  So even if/when the
> > min-width stuff is fixed as we discussed, you will have 4 strings
> > displayed one after the other, and each one of them has the min-width
> > spec, so each one of them will be displayed as at least 5 characters.
> > And that's not what you want here.
> 
> It sounds like much the same thing that happens when doing the
> " (%l,%c)" -- you also get two strings then, which is why the min-width
> end handler checks that we're really at the end of the sequence of strings.

That's sheer luck, an artifact of the particular implementation in
display_min_width.  Specifically, the stretch glyph is appended when
we see a new Lisp string, so the " " separator after those elements
plays that role.  That's why we get that extra space before "@" in the
situation described by this bug report: that "@" is the first Lisp
string that follows mode-line-mule-info, and mode-line-mule-info is
produced as C strings.

So another way to fix this is to introduce a new mode-line construct,
say %=, which will produce either an empty string or "@" for client
frames, as C strings, and use that as mode-line-client element.  Then
all of those 4 elements will be produced as C strings, and the problem
reported in this bug report will be solved.  But then the change we
discussed that would allow processing such properties on C strings
will again break this, because it will apply min-width to each
separate C string in this group of indicators.

Basically, the way we display the mode line with text properties only
works for properties that have the same effect if applied to each part
of a string separately, or to the entire string in one go.  Faces and
help-echo are like that; but the min-width display spec isn't, because
it takes effect when the string _ends_, so where the string ends and
how many strings are there is important for it.  Thus, concatenating
the strings before propertizing is really needed for this to work on a
group of strings.