Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> I do think it's a misfeature: Emacs is a bit trigger happy with windows.
>> When resizing frames/windows, I believe it should generally try to avoid
>> deleting windows when possible.  Patches in this direction are welcome
>> (we have already improved this, e.g. by replacing the C-x + code, with
>> the introduction of adjust-window-trailing-edge, ...).

> Setting `window-min-height' and `window-min-width' to their minimum
> values _should_ handle that.

You mean "should work around this problem".  Yes, I know how to work
around it, but you're not seriously proposing a patch that changes the
defaults for window-min-height and window-min-width to 1, are you?

> If it doesn't we have a bug to fix.  If it does we might reconsider
> the default values.

I think Emacs should try harder not to delete windows, no matter what
the user decided to use for window-min-height and window-min-width.
I.e. shrink some other larger window rather than delete a small window.

>>> One aspect that puzzles me is why, when `window-min-height' equals 1,
>>> Emacs doesn't simply display the window's modeline.
>> 
>> Between the header-line, the mode-line, and the buffer text itself,
>> Emacs assumes here that it's more important to show the buffer text.
>> It may not always be the best choice, but it does make sense.

> It's a terrible choice IMO because it makes the text of the buffer
> displayed in an upper window appear part of the buffer displayed in the
> lower window _without the slightest feedback_.  Moreover, it doesn't
> permit to resize the one-line window by dragging its modeline.

I was just explaining the current behavior.  I wouldn't oppose a change
in this regard, but I don't think it's terribly important.

>>> Another problem is that Emacs doesn't record window sizes accross
>>> (de-)maximizations.  Hence in your ediff control panel example you'd
>>> have to fix the window-height at 1 in order to handle re-maximization as
>>> intended :-(
>> I'm not sure what better behavior you're thinking of.
> Ideally, de-maximizing a maximized frame followed by re-maximizing it
> should restore the previous window sizes.

Yes, of course, but *how*?  Maybe we should associate with each window
an "ideal size" which would be a pair of floating point numbers
indicating the size of the window as a fraction of the frame size.
Whenever the user changes the window's size, this number is modified,
but when the frame size is modified, this number is used to compute
a new window size.  This way the size of windows is preserved by
frame resizing.
Patches welcome.


        Stefan