RE: FW: fit-frame.el

[Drew Adams]

> To me, as a user of your code, I found this behavior to look like your
> code is just buggy: after calling fit-frame on a frame with several
> windows, the result was a frame of different size, where some of the
> windows were too small for their buffers and others were too large, so
> it looked like it was just all messed up.

Perhaps users need to read the doc?

More stress on the one-window use case could be added to the doc, if you
think users are likely to try it on frames with many windows without reading
the doc.

> > There is this TODO item in fit-frame.el:
> 
> > ;;  Emacs needs a command similar to `fit-frame'
> > ;;  for windows, that is, a command that will fit
> > ;;  the existing windows of a frame to their
> > ;;  buffers, as well as possible.  That could be
> > ;;  then be used in combination with `fit-frame'.
> 
> > Until that is available, I think that `fit-frame' does the 
> > best that can be expected. The best use case for it is
> > one-window-p frames, but it can also be useful for other
> > frames, depending on what they are showing. When you are
> > in a context where it is not useful, don't use it. ;-)
> 
> I'm not convinced that this "best we can do" is useful.

No one is forced to call the command. I find it very useful for the
one-window case, and I think it can also be useful for multiple windows,
especially for few windows. It might not be super useful if you have 13
windows in a frame, but for simple cases it can be handy, IMO. The point is
that you only use it when it makes sense for you.

If you think there is some "danger" in providing the multiple-window
behavior, we can add an option that, if non-nil, raises an error if the
command is called for a frame with more than one window. I think that's
silly, but I think I understand what you are saying.

> >> Also when the C-u arg is provided, it seems to resize the 
> >> frame to the size it should have if it displayed only 1 window,
> 
> > Correct (for plain C-u).
> 
> That's what I inferred from the behavior, not from the docstring.
> 
> >> whereas of course it's not the case: there are other windows
> >> there (otherwise C-u makes no difference anyway).  So again,
> >> the result is somewhat unexpected.
> 
> > It's not unexpected if that's what's described in the doc.
> 
> The doc says:
> 
>   To fit the frame to all of its displayed buffers, use no prefix arg.
>   To fit it to just the current buffer, use a plain prefix 
>   arg (`C-u').
> 
> but it's far from clear what might be meant by "fit a frame to the
> current buffer" (unless the current buffer is the only one 
> shown in the frame, that is).

What is meant by "fit a frame to the current buffer" is detailed in the doc
string, starting with "_Fitting a non-empty buffer means_ resizing the frame
to the smallest size such that the following are both true:".

That describes what is meant by fitting a frame to a (non-empty) single
buffer.

> > The main use case to think about here is one-window frames.
> 
> I think it makes sense to restrict its use to one-window-p (and hence
> throw away the C-u argument).  And then rename it to 
> fit-frame-to-buffer.

That was the original behavior. I added the multi-window behavior at user
request. It is useful in some cases. Example: two windows, top and bottom
(e.g. Lisp code and Info). You can resize the frame to shrink-wrap either of
the buffers.

If you have only one window, then the behaviors with and without C-u are the
same.

Why prohibit a user from using this in situations where it is useful?

> We might also want to have a variant that only shrinks the frame.
> Such a variant probably wouldn't need any customization.

Only shrinks it to what size? Using what criteria? There are plenty of
commands to shrink or enlarge frames (I have some). The use case of
fit-frame.el is to fit frames to buffers.