[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 7 Jan 2005 20:32:18 +1300
> > > 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.
I'll show my ignorance: I don't know what a base face is and I can't
find a definition in the manual.
> 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.
Perhaps this should have been mentioned in the manual too.
> 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 use format-mode-line in the version of t-mouse.el that I posted here
recently to make clicking on the mode-line position dependent. It seems to
work with (format-mode-line mode-line-format) but not (format-mode-line). This
relates to an earlier post (format-mode-line and mode-line mouse events - 18
Dec 2004) where I gave an example output. My analysis might be feeble - the
output seems wrong to me but I don't understand what is happening enough to
> 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.
Sure. I don't understand where it would be used but it won't interfere with
my use of format-mode-line.