Re: moving window handling into lisp

[martin rudalics]

> 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