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