RE: FW: fit-frame.el

["Drew Adams" <drew.adams@oracle.com>]

> Could you describe what is the behavior of your function when 
> there are more than 1 windows in the frame?  After trying it out,
> I'm still not sure. 

With no prefix arg, the frame is fit to all of the buffers displayed in it.
This means that, within the maximum frame-size limits (see the doc for these
- user variables), each buffer contributes to the frame size needed. There
is no explicit resizing of windows within the frame. If each buffer can be
shown fully (no display wrapping) with the frame still within its limits,
then each buffer will be shown fully.

The same fitting algorithm is applied to each buffer, to try to find what
would be an ideal fit for it alone. The requisite widths and heights are
summed to produce the overall ideal frame size to show all of the frame's
buffers. Then the frame-size limits are applied.

Obviously, frame fitting is most useful for either one-window frames or
frames with some buffers that are narrow or short (depending on their
positions).

> I get the impression that part of the problem is that you
> calculate a frame size that would allow all windows to have the right
> size, but you don't actually resize the windows, so they get 
> a somewhat arbitrary size which may or may not be the right one.

You can put it that way, if you like. It is by design that there is no
explicit attempt to resize the windows, relative to each other, to achieve
an overall "best window configuration", whatever that might mean (depends on
what you want, in general and in any specific context). But the relative
sizes of windows can change as a side effect, of course.

It's not obvious, for instance, that you would want, say, a proportional
reduction of each window from its ideal shrink-fit size, in order to fit all
of them within the calculated frame size. You might instead want to
privilege one window (display its buffer fully, if possible, or as much of
it as possible). Or you might instead want to privilege some subset of the
windows in different ways.

You might have a set of buffers (e.g. with names matching some regexp) that
you want to always receive more emphasis (privilege during resizing), and
you might have another set that you want to receive less emphasis. You might
also want buffer mode to be taken into account - for example, it make little
sense to measure the width of a line in longlines mode.

Because the possibilities of window sizes within a given frame are numerous
and can depend on user preference, which buffers and modes are involved, and
other things (phase of moon?), it would be an interesting discussion to come
up with a good design that DTRT generally and lets users easily control
relative window resizing.

Designing different window resizing possibilities and how to specify
interactively which of them you want at any time, perhaps in combination
with frame resizing, is, in any case, a task for the future.

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

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

> 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. In many cases,
you might not want that behavior. Don't use plain `C-u' when you don't want
that behavior.

> I'd have expected it to resize the frame so that the window fits the
> buffer, and so that the other windows stay "unchanged".

As I said, windows are not resized, except as a side effect of fitting the
frame. Integrating possible window resizing with frame resizing can be a
future challenge. It's not obvious what window-resizing behavior one might
want in different contexts.

When that possible combination (frame and window resizing) is considered, it
might be useful to revisit the prefix-arg and user option possibilities.
More or different options and prefix-arg values might need to be considered,
to take into account mixing frame and window resizing.

The main use case to think about here is one-window frames. The default
behavior (no prefix arg) also does something for multi-window frames that
can be useful in some contexts, but I expect that most people will use this
as I do, to resize one-window frames.

Another important use case is calling it from Lisp code.

Note: There is a companion library, autofit-frame.el, that provides
automatic frame-fitting for the one-window case (only). However, that
library redefines display-buffer, switch-to-buffer, and pop-to-buffer.
Richard suggested that that logic be incorporated into the C source code,
after fit-frame.el has been added to Emacs. I won't be coding that C code
myself, but I can provide the Lisp code to help with the logic. IMO, it is
very handy to some users, such as I, who use frames the way most users use
windows. Use of automatic frame fitting is optional, of course. 

HTH.