[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: format-mode-line

From: Kim F. Storm
Subject: Re: format-mode-line
Date: Thu, 06 Jan 2005 22:00:58 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

Nick Roberts <address@hidden> writes:

>  >     I suggest changing format-mode-line so that FORMAT is not optional and 
> not
>  >     give a special meaning to nil and t. I think format-mode-line is 
> currently
>  >     always used with a value for FORMAT. If this is a good idea, I offer 
> to do
>  >     it and post my patch here.
>  > 
>  > The argument above seems convincing, so please do.

I see that the following patch has already been installed, but I have problem 
with it.

Specifically, it removes a useful feature of the old code:

When format is nil (for mode-line-format) or t (for header-line-format),
the resulting string is propertized with the proper mode-line and header-line
face as the base face.

This differs from specifying mode-line-format and header-line-format
as this does not put a base face on the formatted string.

With the patch, this distinction is no longer present.

IMHO, the fine thing with the old code was that (format-mode-line
nil) would give you an exact replica (except for the trailing dashes)
of the mode line, whereas (format-mode-line mode-line-format) only
gives an approximation.

The rationale for making FORMAT optional was that (format-mode-line)
should simply do the right thing [IMHO], i.e. return the current mode
line as specified by mode-line-format in the proper mode-line face.

In your original mail you said:

> The manual also says:
> > If FORMAT is `nil', that means to use `mode-line-format'
> This does not seem to make sense because if header-line-format is nil
> then (format-mode-line header-line-format) will presumably return the
> mode-line of selected window as a string.

That is a problem indeed that I didn't think about.

> In any case, (format-mode-line) does not seem to give the right thing,
> although (format-mode-line mode-line-format) does.

I seems to work fine for me -- what is wrong with the return value?

I don't object to the patch as such, but I think it should be possible
somehow to specify the face to use for the string, e.g. we could change
the definition as follows with the following doc string:

(format-mode-line FORMAT &optional FACE WINDOW BUFFER)

Return a mode line format specification as a string.
First arg FORMAT specifies the mode line format (see `mode-line-format'
for details) to use.  Optional second arg FACE is the basic face to
use on the formatted string.  If FACE is nil, the returned string is
not propertized.  Optional third arg WINDOW specifies a different
window to use as the context for the formatting. Fourth optional arg
BUFFER specifies which buffer to use.

If FORMAT is t or the symbol `mode-line', this corresponds to
specifying `mode-line-format' for FORMAT and `mode-line' for FACE.  If
FORMAT is the symbol `header-line', format the `header-line-format' in
the `header-line' face.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]