Re: format-mode-line

[Nick Roberts]

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

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


Nick