Re: [PATCH] Window resizing

[Nick Roberts]

 >     The bug seems to arise because dragging the mode line is done through
 >     enlarge-window which can sometimes move the top of the window rather 
 > than the
 >     bottom.
 > 
 > Perhaps what we need, in order to fix this reliably, is to add a
 > way to call enlarge-window and say "move only the top or left edge".

There are many approaches, all of which are probably thorny.  It needs
extensive rigorous analysis to cover all possibilities, but I think a quick
fix is probably best done in lisp.

 >       mouse.el seems to have an inappropriate constraint on enlarge-window
 >     (third arg t window gets larger).
 >
 > I can't parse that.  Could you explain it less tersely?

I mangled it somehow: third arg is t when the window gets larger

 > The reason for passing t as the third arg is to insist on
 > moving the bottom edge.  That is surely the right thing for
 > it to do in some situations.  Why do you think it is wrong?


The doc says:

  Optional third arg preserve-before, if non-nil, means do not change the size
  of the siblings above or to the left of the selected window

With the configuration given in FOR-RELEASE, dragging second window to the left,
moves the mode line above in unison.  So the selected window stays fixed in
size while the sibling above shrinks and enlarges.

If you require: (enlarge-window growth nil (> growth 0)), that sibling can't
change size when growth is positive.  This means that you can drag the
mode-line down but not up (mouse-drag-move-window-bottom is called with the
window "below", which would get bigger when dragging up (- growth)).

This analysis is empirical.  I don't know why the mode lines move in unison.

Nick