bug#12419: Mouse click changes layout

[martin rudalics]

>> Wouldn't using the "asymmetric" resizing do the job here?  I don't
>> think the symmetric variant is ever TRT when triggered by resizing the
>> minibuffer window.
>
> I think asymmetric would be a better choice, indeed.
>
> IIUC the difference between "asymmetric" and the old "miniwindow-resize"
> behavior is that if the lowest window needs to be shrunk below the
> minimum height, the "miniwindow-resize" just gave up, whereas the
> "asymmetric" will try to resize further windows.

Asymmetric is what shrink_window_lowest_first did in Emacs 23.  It could
shrink all windows down to their safe minimum height.  But there's no
enlarge_window_lowest_first for the obvious reason.  You can't undo the
effect of shrink_window_lowest_first easily.  So Emacs 23 saved the
sizes of windows at the beginning of growing the minibuffer and restored
them, if possible, when shrinking the minibuffer back.  That's also why
the default of `resize-mini-windows' is `grow-only'.  You can't
implement `t' with this method.  And that's also why the echo area
usually gets cleared and sized back immediately.

> I think The Right Thing(tm) lies somewhere between the two:
> - OT1H it's generally a good idea not to grow the miniwindow larger than
>   other windows), hence the old "miniwindow-resize".
> - OTOH, if the window just above the minibuffer is a special tiny window
>   displaying some auxiliary-info, it sometimes makes sense to treat it
>   as a kind of "attachment to the modeline" and to resize the other
>   window instead.

This is a case that must be handled.  Anything else would be a regression.

> So maybe tweaking the asymmetric behavior so it only resizes 1 window
> (typically the window immediately above the modeline, but if that one
> is marked window-size-fixed, then the one above) would be ideal.
>
> In the mean time, I suggest we try to use asymmetric.

This would enlarge a one line window at the bottom of the frame whenever
the minibuffer is shrunk back.  Not a feasible option.  What I have to
do is to save the state (in the window structure to avoid the extra
allocations) before growing the minibuffer and restore it (if the
heights still match) when shrinking the minibuffer back.  This is
cumbersome but I see no other way.

> PS: BTW, I've several times wished that when dragging modelines (and
> vertical dividers), dragging them back would also bring back the other
> dividers.

I had implemented that initially.  It's disconcerting (but I could make
it optional easily).

> OTOH, I haven't had the chance to use an Emacs that would
> behave like that, so maybe if it did I'd often wish that the dividers
> don't move back.

Indeed.

martin