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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 52183 <at> debbugs.gnu.org, dm <at> mssdvd.com
Subject: bug#52183: 29.0.50; Empty space in the mode line if server-mode is active
Date: Sat, 04 Dec 2021 13:59:56 +0200

> Date: Sat, 04 Dec 2021 12:29:28 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 52183 <at> debbugs.gnu.org
> 
> > From: Davide Masserut <dm <at> mssdvd.com>
> > Cc: 52183 <at> debbugs.gnu.org
> > Date: Sat, 04 Dec 2021 10:56:17 +0100
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > > Do you still see this on the current master?  I seem to be unable to
> > > reproduce this today.
> > 
> > I'm still seeing it on "3e7aff5fcdd3fa6e30497323c914f6c79c951ed6".
> 
> Ignore me: I wasn't testing this properly.

I think I understand the root cause of this.

bindings.el produce this part of mode line as follows:

             (list
              :propertize
              (list ""
	            'mode-line-mule-info
	            'mode-line-client
	            'mode-line-modified
	            'mode-line-remote)
              'display '(min-width (5.0)))

This presumes that the values of the mode-line-* variables mentioned
there will be concatenated, then the display property with the
min-width spec added to the result of the concatenation, and then the
result will be displayed.

But that's not how the mode-line display works.  The "concatenation",
as mentioned in the ELisp manual:

  ‘(STRING REST...)’
  ‘(LIST REST...)’
       A list whose first element is a string or list means to process all
       the elements recursively and concatenate the results.

is not a real concatenation that produces a Lisp string, it is a
"effective concatenation" that happens on display, because the
elements of the list are displayed one after the other.  Any string in
the list gets the properties specified in :propertize applied to it
_before_ displaying it, but text properties on C strings are ignored
when they are displayed, and so have no effect.

Now the way min-width is implemented, if we display a series of C
strings, then display a Lisp string, the min-width will have effect
before the Lisp string is displayed.  Which is what happens here: the
"@" indicator is computed in bindings.el as a Lisp string.  Without
the "@" part, the "  " string that follows the above group of
indicators plays the role of that Lisp string, so the min-width thing
_seems_ to work as intended when all the 4 parts above are either C
strings or empty strings.

Bottom line: I think to make this work as intended, bindings.el should
be modified to produce a Lisp string from all those 4 elements, by
concatenating them, and then the min-width display spec should be put
on the result of the concatenation.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.