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

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

[積丹尼 Dan Jacobson]

[-- Attachment #1: Type: text/plain, Size: 111 bytes --]

Here we see gnus still has fluffy whitespace in the mode-line,
despite it running off the side of the screen.


[-- Attachment #2: dw2w.jpg --]
[-- Type: image/jpeg, Size: 3787 bytes --]

[-- Attachment #3: Type: text/plain, Size: 170 bytes --]


In such cases all whitespace should be compacted more...

Gnus v5.13
GNU Emacs 26.1 (build 2, i686-pc-linux-gnu, GTK+ Version 3.24.4)
 of 2019-02-04, modified by Debian

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

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> Here we see gnus still has fluffy whitespace in the mode-line,
> despite it running off the side of the screen.

[...]

> In such cases all whitespace should be compacted more...

I think that's a good idea; anybody got a comment here?

This could be implemented kinda simply by looking at the mode line
string after it's been generated, and shortening spaces if the text is
too long.

For instance, the mode line here says

U:**-  *unsent bla bla bla bla bla bla bla bla*   All L23     (Message MML Fly A

and then I can't see any more.  The spaces before "All" and after "L23"
could be compacted in these situations...

It'd have to be a user option, of course.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:
>
>> Here we see gnus still has fluffy whitespace in the mode-line,
>> despite it running off the side of the screen.
>
> [...]
>
>> In such cases all whitespace should be compacted more...
>
> I think that's a good idea; anybody got a comment here?
>
> This could be implemented kinda simply by looking at the mode line
> string after it's been generated, and shortening spaces if the text is
> too long.
>
> For instance, the mode line here says
>
> U:**-  *unsent bla bla bla bla bla bla bla bla*   All L23     (Message MML Fly A
>
> and then I can't see any more.  The spaces before "All" and after "L23"
> could be compacted in these situations...
>
> It'd have to be a user option, of course.

Instead of, or in addition to, a user option, perhaps a new mode line
construct would be more general.  There is already a way to specify a
minimum field width, for example, so perhaps it would be possible to
also specify a maximum default width.

-- 
Basil

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

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Instead of, or in addition to, a user option, perhaps a new mode line
> construct would be more general.  There is already a way to specify a
> minimum field width, for example, so perhaps it would be possible to
> also specify a maximum default width.

Do you mean on a per-field basis?  Hm...  I'm not sure that's generally
useful -- when chopping down a field, there's often field-specific ways
to shorten things (i.e., just chopping the ends off of things isn't
always the best thing to do).

But in any case, it's orthogonal to whether to compact the white space,
which entails no information loss and can be done generally.  I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Instead of, or in addition to, a user option, perhaps a new mode line
>> construct would be more general.  There is already a way to specify a
>> minimum field width, for example, so perhaps it would be possible to
>> also specify a maximum default width.
>
> Do you mean on a per-field basis?  Hm...  I'm not sure that's generally
> useful -- when chopping down a field, there's often field-specific ways
> to shorten things (i.e., just chopping the ends off of things isn't
> always the best thing to do).
>
> But in any case, it's orthogonal to whether to compact the white space,
> which entails no information loss and can be done generally.  I think.

I had a look at this, thinking that this would be easy to implement.  We
could have, for instance, a variable like `mode-line-compact' that would
default to nil (current behaviour), t (always compact) and `long'
(compact if the mode line is wider than the window size).

However, the mode line generation is done in a very low-level manner --
in display_mode_element.  And it calls display_string directly for each
element?  If I'm reading the code correctly?

static int
display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format)
[...]
  mode_line_target = MODE_LINE_DISPLAY;

Yeah, I think so.

So it doesn't create a string, and then display it, so there's really no
way to post-process the entire string before it's displayed, I think?
Which makes this rather difficult to implement.

Hm...  well, since this is an optional thing users can switch on,
perhaps making it slightly slower wouldn't be that much of a problem.
Let's see...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  well, since this is an optional thing users can switch on,
> perhaps making it slightly slower wouldn't be that much of a problem.
> Let's see...

OK, here's a proof of concept.  With the patch, the mode line looks like:


[-- Attachment #2: Type: image/png, Size: 6516 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2428 bytes --]


If this way of implementing it sounds OK to everybody, then I'll finish
the patch (and add support for "only compact if the line is too long")
and add documentation and NEWS.

diff --git a/src/xdisp.c b/src/xdisp.c
index 4fe1c4288a..938b3b408a 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -25216,14 +25216,42 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format)
 			 format_mode_line_unwind_data (NULL, NULL,
 						       Qnil, false));
 
-  mode_line_target = MODE_LINE_DISPLAY;
-
   /* Temporarily make frame's keyboard the current kboard so that
      kboard-local variables in the mode_line_format will get the right
      values.  */
   push_kboard (FRAME_KBOARD (it.f));
   record_unwind_save_match_data ();
-  display_mode_element (&it, 0, 0, 0, format, Qnil, false);
+
+  if (NILP (Vmode_line_compact))
+    {
+      mode_line_target = MODE_LINE_DISPLAY;
+      display_mode_element (&it, 0, 0, 0, format, Qnil, false);
+    }
+  else
+    {
+      Lisp_Object mode_string = Fformat_mode_line (format, Qnil, Qnil, Qnil);
+      char *string = xmalloc (SBYTES (mode_string) + 1),
+	*ostring = SSDATA (mode_string);
+      char *s = string, prev = 0;
+
+      /* Copy over the data from the mode line string, but ignore
+	 repeating spaces.  This should be safe even for multibyte
+	 strings, since this is UTF-8. */
+      for (int i = 0; i < SBYTES (mode_string); i++)
+	{
+	  char c = ostring[i];
+	  if (!(c == ' ' && prev == ' '))
+	    {
+	      *s++ = c;
+	      prev = c;
+	    }
+	}
+      *s = 0;
+      
+      display_string (string, Qnil, Qnil, 0, 0, &it, 0, 0, 0,
+		      STRING_MULTIBYTE (mode_string));
+      xfree (string);
+    }
   pop_kboard ();
 
   unbind_to (count, Qnil);
@@ -34551,6 +34579,11 @@ syms_of_xdisp (void)
 The face used for trailing whitespace is `trailing-whitespace'.  */);
   Vshow_trailing_whitespace = Qnil;
 
+  DEFVAR_LISP ("mode-line-compact", Vmode_line_compact,
+    doc: /* Non-nil means that mode lines should be compact.
+This means that repeating spaces will be replaced with a single space.  */);
+  Vmode_line_compact = Qnil;
+
   DEFVAR_LISP ("nobreak-char-display", Vnobreak_char_display,
     doc: /* Control highlighting of non-ASCII space and hyphen chars.
 If the value is t, Emacs highlights non-ASCII chars which have the


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 07 Aug 2020 10:31:22 +0200
> Cc: 34476@debbugs.gnu.org,
>  積丹尼 Dan Jacobson <jidanni@jidanni.org>
> 
> -  display_mode_element (&it, 0, 0, 0, format, Qnil, false);
> +
> +  if (NILP (Vmode_line_compact))
> +    {
> +      mode_line_target = MODE_LINE_DISPLAY;
> +      display_mode_element (&it, 0, 0, 0, format, Qnil, false);
> +    }
> +  else
> +    {
> +      Lisp_Object mode_string = Fformat_mode_line (format, Qnil, Qnil, Qnil);
> +      char *string = xmalloc (SBYTES (mode_string) + 1),
> +	*ostring = SSDATA (mode_string);
> +      char *s = string, prev = 0;
> +
> +      /* Copy over the data from the mode line string, but ignore
> +	 repeating spaces.  This should be safe even for multibyte
> +	 strings, since this is UTF-8. */
> +      for (int i = 0; i < SBYTES (mode_string); i++)
> +	{
> +	  char c = ostring[i];
> +	  if (!(c == ' ' && prev == ' '))
> +	    {
> +	      *s++ = c;
> +	      prev = c;
> +	    }
> +	}
> +      *s = 0;
> +      
> +      display_string (string, Qnil, Qnil, 0, 0, &it, 0, 0, 0,
> +		      STRING_MULTIBYTE (mode_string));
> +      xfree (string);
> +    }

Ouch!  This is Lisp converted into C, yes?  And it formats the
mode-line twice: once in format-mode-line, then again in
display_string, right?

You don't need all this inelegance.  After display_mode_element
returns, you have all the glyphs it produced in it.glyph_row, so you
can simply remove the unneeded space glyphs from the glyph row (and
adjust the metrics accordingly).  Let me know if you need more
detailed help in how to do that.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> +	  char c = ostring[i];
>> +	  if (!(c == ' ' && prev == ' '))
>> +	    {
>> +	      *s++ = c;
>> +	      prev = c;
>> +	    }

[...]

> Ouch!  This is Lisp converted into C, yes?

If that looks like Lisp to you...  :-)

> And it formats the mode-line twice: once in format-mode-line, then
> again in display_string, right?

No, display_string just displays the string, I think?

> You don't need all this inelegance.  After display_mode_element
> returns, you have all the glyphs it produced in it.glyph_row, so you
> can simply remove the unneeded space glyphs from the glyph row (and
> adjust the metrics accordingly).  Let me know if you need more
> detailed help in how to do that.

That seems like a lot more work, I think?  And I don't see how that
could be more efficient than just removing the characters from the C
string?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Fri, 07 Aug 2020 13:41:15 +0200
> 
> > And it formats the mode-line twice: once in format-mode-line, then
> > again in display_string, right?
> 
> No, display_string just displays the string, I think?

Which is a non-trivial amount of work: loading all the font glyphs
again and accounting for their metrics, considering the faces, etc.
All of which was already done.

> > You don't need all this inelegance.  After display_mode_element
> > returns, you have all the glyphs it produced in it.glyph_row, so you
> > can simply remove the unneeded space glyphs from the glyph row (and
> > adjust the metrics accordingly).  Let me know if you need more
> > detailed help in how to do that.
> 
> That seems like a lot more work, I think?

Why a lot more work?  It's basically the same loop as you do on
characters of the string produced by Fformat_mode_line, just done on
elements of it.glyph_row->glyphs[TEXT_AREA], which is a linear array
of 'struct glyph'.  Each glyph tells you what character it displays
(and much more).  There are gobs of similar code in xdisp.c.  For
example, here's how we make space in a glyph row for prepending a
character (needed when displaying R2L lines):

	  struct glyph *g;

	  /* Make room for the additional glyph.  */
	  for (g = glyph - 1; g >= it->glyph_row->glyphs[area]; g--)
	    g[1] = *g;
	  glyph = it->glyph_row->glyphs[area];

IOW, it's just an array of simple objects, not unlike array of
characters, a.k.a. "a string".

If this still sounds complicated, I can volunteer to write the code
myself, if you promise to write tests for the feature ;-)

Thanks.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > And it formats the mode-line twice: once in format-mode-line, then
>> > again in display_string, right?
>> 
>> No, display_string just displays the string, I think?
>
> Which is a non-trivial amount of work: loading all the font glyphs
> again and accounting for their metrics, considering the faces, etc.
> All of which was already done.

I'm not very familiar with that code, but from my reading of it, none of
that has been done at this point.

I call Fformat_mode_line (format, Qnil, Qnil, Qnil); instead of
display_mode_element.  Fformat_mode_line sets

  mode_line_target = MODE_LINE_STRING;

or the like, and then calls display_mode_element, which then won't call
display_string at all, but just put all the computed elements in a list.

So nothing is displayed until that call to display_string, in my reading
of the code.

OK, I've now done some more testing -- I removed my call to
display_string, and no mode line is displayed at all, which kinda
supports my reading of the code?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Fri, 07 Aug 2020 14:15:21 +0200
> 
> So nothing is displayed until that call to display_string, in my reading
> of the code.

Nitpicking: display_string doesn't display anything, it just prepares
glyph structures used by other code to actually display the mode line
on the glass.

> OK, I've now done some more testing -- I removed my call to
> display_string, and no mode line is displayed at all, which kinda
> supports my reading of the code?

I don't want to argue with your reading of the code.  I'm saying that
the natural way of removing extra spaces is to post-process the glyphs
produced by display_string directly; anything else is IMO inelegant
and unnatural.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> OK, I've now done some more testing -- I removed my call to
>> display_string, and no mode line is displayed at all, which kinda
>> supports my reading of the code?
>
> I don't want to argue with your reading of the code.  I'm saying that
> the natural way of removing extra spaces is to post-process the glyphs
> produced by display_string directly; anything else is IMO inelegant
> and unnatural.

I just don't understand why -- pre-processing the string is more
efficient and...  normal...  than post-processing the glyphs, surely?
Preparing a string and then calling the display functions is what we do
all over the place.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Sat, 08 Aug 2020 11:11:48 +0200
> 
> > I don't want to argue with your reading of the code.  I'm saying that
> > the natural way of removing extra spaces is to post-process the glyphs
> > produced by display_string directly; anything else is IMO inelegant
> > and unnatural.
> 
> I just don't understand why -- pre-processing the string is more
> efficient and...  normal...  than post-processing the glyphs, surely?
> Preparing a string and then calling the display functions is what we do
> all over the place.

You don't really have a string here, you need to generate it first,
from several individual C and Lisp strings, and from :eval
expressions.  Generating it involves employing some of the same code
that display_mode_element calls, but in a context that was not meant
for display, so I'm not even sure the result will be the same (i.e. we
risk inadvertent changes in behavior).  We will also be consing at
least one more Lisp string, so displaying a mode-line under this
option will produce more garbage.  All of these are IMO disadvantages
that don't exist in my proposal.

And I don't see why post-processing would be less efficient.  Can you
explain why you think so?

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

[Eli Zaretskii]

> Date: Sat, 08 Aug 2020 12:48:30 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: contovob@tcd.ie, 34476@debbugs.gnu.org, jidanni@jidanni.org
> 
> And I don't see why post-processing would be less efficient.  Can you
> explain why you think so?

Should I perhaps post the post-processing code I had in mind?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> You don't really have a string here, you need to generate it first,
> from several individual C and Lisp strings, and from :eval
> expressions.  Generating it involves employing some of the same code
> that display_mode_element calls, but in a context that was not meant
> for display, so I'm not even sure the result will be the same (i.e. we
> risk inadvertent changes in behavior).  We will also be consing at
> least one more Lisp string, so displaying a mode-line under this
> option will produce more garbage.  All of these are IMO disadvantages
> that don't exist in my proposal.

Ah, I misunderstood what you meant here -- I thought you wanted to
change my patch to call display_string on the result from
Fformat_mode_line, and then alter the glyph matrix.  :-/

But, yes, what you're saying makes total sense -- rendering the mode
line as normal, and then changing the glyphs to remove the spaces would
be more efficient and create less garbage.

I didn't think this extra garbage on mode line updates didn't matter
much, especially since `mode-line-compact' would be a user option
defaulting to nil.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> And I don't see why post-processing would be less efficient.  Can you
>> explain why you think so?
>
> Should I perhaps post the post-processing code I had in mind?

Yes, please.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Sat, 08 Aug 2020 13:18:30 +0200
> 
> > Should I perhaps post the post-processing code I had in mind?
> 
> Yes, please.  :-)

Something like the below, tested very lightly (need test cases with
various non-default faces and fonts in the mode line, and also
images).

Note a few subtle issues:

 . I've limited the feature to the mode line; programs that set
   header-line and tab-line either don't want this, or should format
   those lines to not waste screen space to begin with;
 . I've refrained from squeezing spaces if they have non-default
   faces, on the assumption that those spaces are significant -- the
   result is that the trailing spaces of the buffer name are not
   squeezed, but I think we have no choice here, as down that path
   lies madness (think a mode line that plays some fancy games with
   font sizes).

diff --git a/src/xdisp.c b/src/xdisp.c
index 4fe1c42..24a621d 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -25228,6 +25228,51 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format)
 
   unbind_to (count, Qnil);
 
+  /* Optionally, squeeze embedded whitespace in the mode line to
+     prevent unnecessary truncation of meaningful data shown there.  */
+  if ((face_id == MODE_LINE_FACE_ID
+       || face_id == MODE_LINE_INACTIVE_FACE_ID)
+      && Vmode_line_compact)
+    {
+      /* Find the last non-blank glyph.  */
+      int last_idx = it.glyph_row->used[TEXT_AREA] - 1;
+      struct glyph *glyphs = it.glyph_row->glyphs[TEXT_AREA];
+      for ( ; last_idx > 0; last_idx--)
+	{
+	  if (!(glyphs[last_idx].type == CHAR_GLYPH
+		&& glyphs[last_idx].u.ch == ' '))
+	    break;
+	}
+
+      /* Now squeeeze embedded repeating spaces.  */
+      int from_idx, to_idx;
+      last_idx++;
+      for (from_idx = 0, to_idx = 0; from_idx < last_idx; to_idx++)
+	{
+	  if (to_idx != from_idx)
+	    glyphs[to_idx] = glyphs[from_idx];
+	  if (glyphs[from_idx].type == CHAR_GLYPH
+	      /* Leave alone spaces that have non-default face ID.  */
+	      && glyphs[from_idx].face_id == face_id
+	      && glyphs[from_idx].u.ch == ' ')
+	    {
+	      from_idx++;
+	      while (from_idx < last_idx
+		     && glyphs[from_idx].face_id == face_id
+		     && glyphs[from_idx].type == CHAR_GLYPH
+		     && glyphs[from_idx].u.ch == ' ')
+		{
+		  it.current_x -= glyphs[from_idx].pixel_width;
+		  from_idx++;
+		}
+	    }
+	  else
+	    from_idx++;
+	}
+      /* Update the count of the glyph slots we've used.  */
+      it.glyph_row->used[TEXT_AREA] -= from_idx - to_idx;
+    }
+
   /* Fill up with spaces.  */
   display_string (" ", Qnil, Qnil, 0, 0, &it, 10000, -1, -1, 0);
 

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

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> Note a few subtle issues:
>
>  . I've limited the feature to the mode line; programs that set
>    header-line and tab-line either don't want this, or should format
>    those lines to not waste screen space to begin with;

Yup.

>  . I've refrained from squeezing spaces if they have non-default
>    faces, on the assumption that those spaces are significant -- the
>    result is that the trailing spaces of the buffer name are not
>    squeezed, but I think we have no choice here, as down that path
>    lies madness (think a mode line that plays some fancy games with
>    font sizes).

Right, so with the patch, I get these two mode lines (with and without
compaction): 


[-- Attachment #2: Type: image/png, Size: 21559 bytes --]

[-- Attachment #3: Type: text/plain, Size: 587 bytes --]


There's four spaces between *scratch* and All because they have
different faces...  which makes me wonder why there's trailing spaces in
the buffer name at all, instead of just three spaces after the buffer
name in the mode line format?  But that's a different issue; the patch
looks great.

There's also the question of allowing a value of `long' to
mode-line-compact -- which would only compact the mode line if it's
longer than the window width.  Would that be difficult to add?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org
> Date: Sat, 08 Aug 2020 16:16:04 +0200
> 
> There's four spaces between *scratch* and All because they have
> different faces...  which makes me wonder why there's trailing spaces in
> the buffer name at all, instead of just three spaces after the buffer
> name in the mode line format?

That's because mode-line-buffer-identification uses %12b as the format
to show the buffer name.

> There's also the question of allowing a value of `long' to
> mode-line-compact -- which would only compact the mode line if it's
> longer than the window width.  Would that be difficult to add?

No, it should be an almost trivial addition to the condition under
which we perform the squeezing.  Basically, compare it.current_x with
it.last_visible_x.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> There's four spaces between *scratch* and All because they have
>> different faces...  which makes me wonder why there's trailing spaces in
>> the buffer name at all, instead of just three spaces after the buffer
>> name in the mode line format?
>
> That's because mode-line-buffer-identification uses %12b as the format
> to show the buffer name.

Yes, I was wondering whether that should be changed to something that's
just %b and then something that inserts some more spaces for short
buffer names...

Alternatively, we could compact spaces if the face doesn't use a
background colour?  Hm...

>> There's also the question of allowing a value of `long' to
>> mode-line-compact -- which would only compact the mode line if it's
>> longer than the window width.  Would that be difficult to add?
>
> No, it should be an almost trivial addition to the condition under
> which we perform the squeezing.  Basically, compare it.current_x with
> it.last_visible_x.

Right.  Do you want to apply your patch (to a branch?) and I can tweak
it further and add documentation and stuff?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org
> Date: Sun, 09 Aug 2020 11:56:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> There's four spaces between *scratch* and All because they have
> >> different faces...  which makes me wonder why there's trailing spaces in
> >> the buffer name at all, instead of just three spaces after the buffer
> >> name in the mode line format?
> >
> > That's because mode-line-buffer-identification uses %12b as the format
> > to show the buffer name.
> 
> Yes, I was wondering whether that should be changed to something that's
> just %b and then something that inserts some more spaces for short
> buffer names...

Yes, I think so.

> Alternatively, we could compact spaces if the face doesn't use a
> background colour?  Hm...

I'm actually more bothered by faces that affect the font.  So I'd
rather we didn't mess with non-default faces in this case.

> > No, it should be an almost trivial addition to the condition under
> > which we perform the squeezing.  Basically, compare it.current_x with
> > it.last_visible_x.
> 
> Right.  Do you want to apply your patch (to a branch?) and I can tweak
> it further and add documentation and stuff?

Will do.

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

[Eli Zaretskii]

> Date: Sun, 09 Aug 2020 17:07:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: contovob@tcd.ie, 34476@debbugs.gnu.org
> 
> > Right.  Do you want to apply your patch (to a branch?) and I can tweak
> > it further and add documentation and stuff?
> 
> Will do.

While doing some further testing, I found a flaw in the implementation
that I need to resolve before pushing the branch.  I have an idea, but
I need to test how well it works.

So it will take me a couple more days.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> While doing some further testing, I found a flaw in the implementation
> that I need to resolve before pushing the branch.  I have an idea, but
> I need to test how well it works.
>
> So it will take me a couple more days.

Sure, no problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> Date: Mon, 10 Aug 2020 17:46:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: contovob@tcd.ie, 34476@debbugs.gnu.org
> 
> While doing some further testing, I found a flaw in the implementation
> that I need to resolve before pushing the branch.  I have an idea, but
> I need to test how well it works.

Turns out my original idea of post-processing the glyphs is
unworkable.  The problem I didn't consider is that glyphs are only
produced up to the limit of the window-width, so once the full
mode-line becomes longer than that, any post-processing cannot
recover the glyphs beyond the window edge, because they were never
produced in the first place.

The alternative which I would like to try implementing is to modify
the code of display_string so that it doesn't produce multiple space
glyphs, replacing them with a single glyph, when this option is
non-nil.  Since display_mode_element always calls display_string to
produce the glyphs, this should allow us to solve the problem cleanly.
Stay tuned.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The alternative which I would like to try implementing is to modify
> the code of display_string so that it doesn't produce multiple space
> glyphs, replacing them with a single glyph, when this option is
> non-nil.  Since display_mode_element always calls display_string to
> produce the glyphs, this should allow us to solve the problem cleanly.
> Stay tuned.

Sounds good...  but I guess this wouldn't allow us to do the `long'
version of the variable?  (I.e., only compact if the line is too long.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org
> Date: Fri, 14 Aug 2020 14:00:16 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The alternative which I would like to try implementing is to modify
> > the code of display_string so that it doesn't produce multiple space
> > glyphs, replacing them with a single glyph, when this option is
> > non-nil.  Since display_mode_element always calls display_string to
> > produce the glyphs, this should allow us to solve the problem cleanly.
> > Stay tuned.
> 
> Sounds good...  but I guess this wouldn't allow us to do the `long'
> version of the variable?  (I.e., only compact if the line is too long.)

We could perhaps do that at the price of producing the glyphs twice:
first without squeezing spaces, then with squeezing if the result is a
truncated mode line.

But first I need to see if this new idea "holds water".

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

[Eli Zaretskii]

> Date: Fri, 14 Aug 2020 13:46:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: contovob@tcd.ie, 34476@debbugs.gnu.org
> 
> The alternative which I would like to try implementing is to modify
> the code of display_string so that it doesn't produce multiple space
> glyphs, replacing them with a single glyph, when this option is
> non-nil.  Since display_mode_element always calls display_string to
> produce the glyphs, this should allow us to solve the problem cleanly.
> Stay tuned.

Here's the result.  Note that this is slightly sub-optimal, because if
2 Lisp strings are displayed one after another, and the first one ends
with a space, while the second one begins with a space, this will not
be squeezed, because we consider each string separately.  If this is
not acceptable, then we will have to go back to your original proposal
of using Fformat_mode_line (although I'm still unhappy with doing
that, as we had over the years quite a few complaints that the result
is not exactly identical to the displayed mode line).

If the patch below is deemed "good enough", we will probably need to
implement something similar for Fformat_mode_line, because users might
expect the latter to produce a similarly squeezed whitespace.

diff --git a/src/xdisp.c b/src/xdisp.c
index 4fe1c42..d9f6bea 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -26883,6 +26883,25 @@ display_string (const char *string, Lisp_Object lisp_string, Lisp_Object face_st
   row->phys_height = it->max_phys_ascent + it->max_phys_descent;
   row->extra_line_spacing = it->max_extra_line_spacing;
 
+  bool space_seen = false;
+  bool squeeze_spaces_p = false;
+  if (!NILP (Vmode_line_compact))
+    {
+      int remapped_modeline_face_id = MODE_LINE_FACE_ID;
+      int remapped_inactive_modeline_face_id = MODE_LINE_INACTIVE_FACE_ID;
+      if (!NILP (Vface_remapping_alist))
+	{
+	  remapped_modeline_face_id
+	    = lookup_basic_face (it->w, it->f, MODE_LINE_FACE_ID);
+	  remapped_inactive_modeline_face_id
+	    = lookup_basic_face (it->w, it->f, MODE_LINE_INACTIVE_FACE_ID);
+	}
+      /* We only squeeze multiple spaces when displaying mode lines.  */
+      squeeze_spaces_p
+	= (it->base_face_id == remapped_modeline_face_id
+	   || it->base_face_id == remapped_inactive_modeline_face_id);
+    }
+
   if (STRINGP (it->string))
     it_charpos = IT_STRING_CHARPOS (*it);
   else
@@ -26898,6 +26917,19 @@ display_string (const char *string, Lisp_Object lisp_string, Lisp_Object face_st
       if (!get_next_display_element (it))
 	break;
 
+      if (squeeze_spaces_p)
+	{
+	  if (it->char_to_display == ' ' && it->face_id == it->base_face_id)
+	    {
+	      if (space_seen)
+		goto next_char;
+	      else
+		space_seen = true;
+	    }
+	  else
+	    space_seen = false;
+	}
+
       /* Produce glyphs.  */
       x_before = it->current_x;
       n_glyphs_before = row->used[TEXT_AREA];
@@ -26962,6 +26994,7 @@ display_string (const char *string, Lisp_Object lisp_string, Lisp_Object face_st
       if (i < nglyphs)
 	break;
 
+    next_char:
       /* Stop at line ends.  */
       if (ITERATOR_AT_END_OF_LINE_P (it))
 	{

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Here's the result.  Note that this is slightly sub-optimal, because if
> 2 Lisp strings are displayed one after another, and the first one ends
> with a space, while the second one begins with a space, this will not
> be squeezed, because we consider each string separately.

Hm...  I think the main use case for squeezing isn't really removing
spaces from individual strings, but consider the entire resulting mode
line as a whole.  We end up with too-spacey mode lines, often, because
we have formats that may or may not display something, but we still have
spaces surrounding that element.

> If this is not acceptable, then we will have to go back to your
> original proposal of using Fformat_mode_line

Yeah, I think that may be the way to go.

> (although I'm still unhappy with doing that, as we had over the years
> quite a few complaints that the result is not exactly identical to the
> displayed mode line).

Perhaps that's something that can be fixed?

> If the patch below is deemed "good enough", we will probably need to
> implement something similar for Fformat_mode_line, because users might
> expect the latter to produce a similarly squeezed whitespace.

Yup.  Perhaps the squeezing should just be moved into that function?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org
> Date: Sat, 15 Aug 2020 12:55:33 +0200
> 
> > If this is not acceptable, then we will have to go back to your
> > original proposal of using Fformat_mode_line
> 
> Yeah, I think that may be the way to go.
> 
> > (although I'm still unhappy with doing that, as we had over the years
> > quite a few complaints that the result is not exactly identical to the
> > displayed mode line).
> 
> Perhaps that's something that can be fixed?

Not easily, because the display engine uses a different environment,
and also temporarily changes various settings as needed, something you
cannot do in Lisp.

> > If the patch below is deemed "good enough", we will probably need to
> > implement something similar for Fformat_mode_line, because users might
> > expect the latter to produce a similarly squeezed whitespace.
> 
> Yup.  Perhaps the squeezing should just be moved into that function?

See above.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > (although I'm still unhappy with doing that, as we had over the years
>> > quite a few complaints that the result is not exactly identical to the
>> > displayed mode line).
>> 
>> Perhaps that's something that can be fixed?
>
> Not easily, because the display engine uses a different environment,
> and also temporarily changes various settings as needed, something you
> cannot do in Lisp.

Hm, ok...  Are these obscure differences?  I just went through a handful
of buffers in this Emacs, and as far as I'm able to eyeball,
(insert (format-mode-line mode-line-format)) produces something that
looks identical to what's in the mode line in all the buffers.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org
> Date: Sun, 16 Aug 2020 13:21:38 +0200
> 
> >> Perhaps that's something that can be fixed?
> >
> > Not easily, because the display engine uses a different environment,
> > and also temporarily changes various settings as needed, something you
> > cannot do in Lisp.
> 
> Hm, ok...  Are these obscure differences?  I just went through a handful
> of buffers in this Emacs, and as far as I'm able to eyeball,
> (insert (format-mode-line mode-line-format)) produces something that
> looks identical to what's in the mode line in all the buffers.

Yes, the problems are subtle and appear rarely.  Some of them were
even fixed during the years.

I'm just bothered that we will shoot ourselves in the foot by
providing a feature that will cause bug reports which will be
non-trivial to fix.  But maybe I worry too much...

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, the problems are subtle and appear rarely.  Some of them were
> even fixed during the years.
>
> I'm just bothered that we will shoot ourselves in the foot by
> providing a feature that will cause bug reports which will be
> non-trivial to fix.  But maybe I worry too much...

Perhaps this will prod us into uncovering and fixing the last few
glitches.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org
> Date: Mon, 17 Aug 2020 10:33:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes, the problems are subtle and appear rarely.  Some of them were
> > even fixed during the years.
> >
> > I'm just bothered that we will shoot ourselves in the foot by
> > providing a feature that will cause bug reports which will be
> > non-trivial to fix.  But maybe I worry too much...
> 
> Perhaps this will prod us into uncovering and fixing the last few
> glitches.  :-)

One can dream.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Perhaps this will prod us into uncovering and fixing the last few
>> glitches.  :-)
>
> One can dream.

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> 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?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

Yup.  I was also not quite sure of the selected_window itself -- can the
mode line be updated while another window is selected?  But I tried
various scenarios, and I couldn't get it to pick the wrong window to do
the computation on.  So perhaps that bit is OK?

> 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?

Yup; will do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34476@debbugs.gnu.org
> Date: Tue, 29 Dec 2020 16:07:50 +0100
> 
> I was also not quite sure of the selected_window itself -- can the
> mode line be updated while another window is selected?

The function display_mode_line doesn't produce the updated mode-line
contents for the selected window, it produces it for the window passed
as its first argument W.  So instead of this:

	  && window_body_width (XWINDOW (selected_window), false) >=

I think you should use this:

	  && window_body_width (w, false) >=

> > 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?
> 
> Yup; will do.

Thanks.

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

[martin rudalics]

 > The function display_mode_line doesn't produce the updated mode-line
 > contents for the selected window, it produces it for the window passed
 > as its first argument W.  So instead of this:
 >
 > 	  && window_body_width (XWINDOW (selected_window), false) >=
 >
 > I think you should use this:
 >
 > 	  && window_body_width (w, false) >=

Better

           && WINDOW_TOTAL_COLS (w) >=

because the mode line covers the entire width of the window (think of
those people using extra large margins).

martin

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

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> The function display_mode_line doesn't produce the updated mode-line
>> contents for the selected window, it produces it for the window passed
>> as its first argument W.  So instead of this:
>>
>> 	  && window_body_width (XWINDOW (selected_window), false) >=
>>
>> I think you should use this:
>>
>> 	  && window_body_width (w, false) >=
>
> Better
>
>           && WINDOW_TOTAL_COLS (w) >=
>
> because the mode line covers the entire width of the window (think of
> those people using extra large margins).

Good point; I've now made both these adjustments.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no