RE: Speedbar mode line is far too wide

[Drew Adams]

    > The mode line centers "Files ####" (where #### is a number) between 64
    > black spaces and "<<" and ">>". This is needlessly wide.
    >
    > If, for example, frame-fitting code is used, the "Files ####" usually
    > disappears off to the right, because the buffer text (when collapsed)
    > is much narrower.
    >
    > Please use just "<< Files #### >>" or similar, with no extra padding.

    Could you please send a complete recipe, starting from "emacs -Q", to
    reproduce the problem, i.e. actually to see some important information
    to disappear?  I cannot understand what is wrong from the info you
    posted, and in particular what is ``frame-fitting code''.  Just
    starting Speedbar in "emacs -Q", everything looks fine to me (I tried
    in the `lisp' directory, where there are several hundreds of files).

It took me a while to find the problem. If the other speedbar bug I filed is
fixed, it will take care of this bug too - see thread "speedbar-frame-mode
calls dframe-frame-mode too early".

The problem is that the speedbar frame is created with an empty buffer. My
own code automatically resizes such an empty frame when it is created, to a
width of, say, 80.

Then, `speedbar-set-mode-line-format' is run, which picks up the current
frame width (80) and uses it to create a mode-line that is that wide (~80).

Then, the speedbar buffer is finally filled, and it is much narrower than
80.

If I then fit the speedbar frame to the (filled) buffer, the mode line stays
at 80, so its text is off the display (too far to the right).

The problem is that the mode-line text width is set once and for all, based
on the frame width at the time the frame is created (or just thereafter),
when the buffer is empty. In Emacs -q, this works OK, because the frame is
still at its default size of 20 (and 20 is narrow enough to be good for all
purposes). In my case, the size is 80 because the frame has been resized
upon creation to a default size that I use for empty frames.

The solution is to fill the speedbar buffer *before* creating its frame.
That will take care of both bugs. Alternatively, a fix for this bug only is
to use (min (speedbar-frame-width) 20) instead of (or (speedbar-frame-width)
20), or just use 20.