bug#7307: 24.0.50; Mode line had more than just dashes removed

[Stephen Berman]

On Mon, 08 Nov 2010 13:28:17 -0500 Stefan Monnier <monnier@iro.umontreal.ca> 
wrote:

(Sorry about the delay; I couldn't get back to it sooner.)

>> How about something like the following patch?
>
> Looks pretty good.  It should probably come together with a Lisp part
> that removes the current mode-line-format change.

See the attached patch.

>> This builds the string
>> dynamically by filling decode_mode_spec_buf to the desired length,
>> dispensing with an additional lots_of_<foo> string.  AFAICT this gives
>> good results (though I admittedly haven't been able to find a case where
>> lots_of_filler (replacing lots_of_dashes) is used; what is such a
>> case?).
>
> I guess the lots_of_filler case is when you use things like "%5-".

?? That's not a documented mode line %-spec, is it?  Anyway, using it I
still see no difference.

>> I also exposed the string character variable mode_line_filler to Lisp,
>> so it could be customizable, but I haven't been able to figure out how
>> to update the mode line with a new character.
>
> That's because you re-initialize mode_line_filler each time.
> Instead you should initialize it once and "for all" in init_xdisp.
> But indeed, that exposes another problem: being global, you won't be
> able to have "----" in tty frames and "    " in GUI frames in the
> same process.

I've discovered, if I'm not mistaken, that it apparently isn't necessary
to initialize mode_line_filler at the C level at all: rather, this can
be done in cus-start.el, and (except with --daemon, see below) it
correctly distinguishes tty and GUI frames.  (Admittedly, I don't
understand why it works, and would be grateful if you or someone else
could tell me.)

>> Also, I don't know the right way to set the default value: I assume it
>> shouldn't be done in decode_mode_spec() as below but at the top level
>> together with the DEFVAR, but then how can it be associated with the
>> window whose mode line is being constructed?
>
> Indeed.  You could use a terminal property instead of (or additionally
> to) a global variable, or you could let the global variable be a cons
> cell where the car is the char to use for GUI frames and the cdr is for
> tty frames :-(

It turns out to be much simpler (if I'm not mistaken).  That is, the
attached patch (against trunk from 2010-11-11) at least appears to DTRT,
except for three issues:

(i) As Andreas already noted, this does not work for non-ASCII
characters, which show up as octal codes.  I haven't yet figured out how
to fix this (I tried using string_make_multibyte, but then attempting to
use a non-ASCII character as the filler makes Emacs crash).

(ii) Using the character customization type and trying to set the filler
character to SPC signals the error "This field should contain a single
character".  I looked at the code but failed to see why this happens.
The patch below contains a workaround I found in ruler.el: allowing the
filler to choose between character and integer type; choosing the latter
with value 32 results in spaces filling the mode line.

(iii) Starting Emacs with --daemon and then opening a frame with
emacsclient -c results in the mode line being filled with `-'
characters, because the daemon uses a tty frame.  Moreover, the Custom
buffer for mode-line-filler says the state was "CHANGED outside
Customize", even with -Q.

If these three issues, or at least the first two, can be dealt with, do
you think this is a reasonable way to make the mode line filler
customizable?

Steve Berman

emacs5.diff
Description: mode line filler patch