Re: moving window handling into lisp

[martin rudalics <rudalics@gmx.at>]

 > One of the benefits of moving window resizing into Lisp
 > is that people will be able to easiy try out various different
 > ways of doing it.  So we need not try to decide the best way
 > by a discussion about abstractions now.
 >
 > It will be possible to have different resizing strategies for
 > different situations, too.  Responding to a window manager need not be
 > the same as responding to the user's dragging a boundary.

Currently, resizing a window W vertically is implemented by the
following routines:

- `enlarge_window' resizes W by stealing/giving space from/to windows
   above and/or below W and may delete windows when they get too small.
   `enlarge_window' does it's job by always calling `set_window_height'
   (see below) with the NODELETE argument 0 so it essentially always gets
   it's job done.  Note that `enlarge_window' is the routine implementing
   the commands `enlarge-window' and `shrink-window' so the majority of
   Emacs' window resizing operations is done here.

- `set_window_height' deletes windows when called by `enlarge_window'
   and display initialization (but this should hardly matter) and
   currently tries to not delete windows when called by the frame
   resizing routines (unless there's no other way because the windows
   won't fit).  Generally, `set-window_height' only serves as an
   interface to `size_window' (see below).

- `size_window' is the basic resizing routine.  It currently can either
   delete other windows unconditionally, delete other windows only when
   they shrink below `window-min-height', or delete them when they shrink
   to zero.  It apparently doesn't handle fixed-size windows correctly
   and does a poor job re-resizing windows.

- `adjust_window_trailing_edge' resizes W by stealing/giving space
   from/to the window below W and does not delete windows when they get
   too small.  `adjust_window_trailing_edge' is used when dragging a
   modeline or vertical divider and calls size_window with the NODELETE
   argument 0.  Due to its ability to not delete any windows it's also
   called by `balance-windows-area'.  To avoid that a window gets deleted
   it saves and restores window-configuration but this could be likely
   resolved by having it call size_window with NODELETE non-zero.  Due to
   the bug in `size_window', `adjust_window_trailing_edge' doesn't handle
   fixed-size windows correctly.

- `delete_window' resizes either the sibling above or below W and is not
   allowed to delete other windows.  So inherently `delete_window' is not
   able to handle fixed-size windows correctly even if size_window were.

- `split-window' resizes only W (where W is the window that shall be
   split) and does not delete any other window.  Currently,
   `split-window' is trivial because it operates on leaf windows only.
   As a consequence, you can, for example, never create a full-width
   window in a frame with two side-by-side windows without deleting one
   of these windows first which I consider a considerable drawback.  If
   `split-window' were allowed to split internal windows, some more
   intelligent resizing routine would be needed.

- `resize_mini_window' shrinks windows above W (where W is the
   minibuffer window) using a routine called `shrink_window_lowest_first'
   which does not delete windows.  `resize_mini_window' can also enlarge
   other windows by calling `enlarge_window' which should not delete any
   window (but I'm not 100% sure about that).  Also `resize_mini_window'
   saves the original sizes of windows shrunk/enlarged in the
   `orig_total_lines' and `orig_top_line' slots and uses these to restore
   the original values when it's job is done (something like a built-in
   version of saving and restoring the window configuration)

With the exception of `resize_mini_window' similar behaviors apply for
resizing W horizontally.

Even if we don't implement resizing in Elisp the following issues have
not been discussed yet:

- Whether resizing may delete other windows depends on the interface to
   size_window chosen.  We can easily make `enlarge-window' not delete
   other windows by giving it an optional `no-delete' argument.  It's not
   clear though whether `size_window' does handle the NODELETE argument
   always correctly.

- Many parts of Emacs might rely on the ability of `enlarge-window' to
   delete other windows.  (It's hard to say which because there are too
   many.)  So some intelligent way of deleting other windows might be
   needed anyway if we wanted `enlarge-window' to not delete any windows.

- Ideally, we would have one function doing the job of `size_window' and
   that function could be used by `resize_mini_window' as well.  That
   function would probably take all the arguments `size_window' currently
   does.  And that function would have to handle fixed-size windows
   correctly and re-resize windows using David's fractional heights and
   widths.

martin