bug#6385: A slightly less aggressive fit-window-to-buffer

[Drew Adams]

>  >> Please post a recipe for reproducing the problem.  I never had any
>  >> problem with this in practice so I can't tell.
>  >
>  > Huh? You yourself said this:
>  >
>  >>> I don't know of a simple way to prevent deletion of 
>  >>> windows when using `enlarge-window'.  The problems with 
>  >>> `fit-window-to-buffer' are just a special case of that.
>  >
>  > Any you said this:
>  >
>  >>>> Deleting other windows when resizing was a misguided feature.
>  >
>  > That "misguided feature" is precisely the problem.  You 
>  > recognize it, so you must have sufficient recipes to produce it.
> 
> This "misguided feature" is in Emacs ever since I know it.

I believe you.  But I've never come across it before.

> But you said that ...
> 
>  > And unfortunately, I need my code to work in multiple 
>  > Emacs versions.  It is only for Emacs 23 (.1 and .2 and more
>  > recent) that this is a problem - I do not see it happening
>  > before 23. So even if you might have a more recent version with
>  > a fix I will still need a workaround for use with Emacs 23.
> 
> ... and that's what I want a recipe for: A reproducible problem that
> does _not_ exist in prior Emacs versions.

Sorry, I cannot take the time to try to pare things down to a single small case.
Suffice it to say that I have never run into the problem before Emacs 23. In my
case, this is about `fit-window-to-buffer' - that is where I see the problem.

>  > Also, if you have some private code that removes this 
>  > "misguided feature", why does vanilla Emacs itself still suffer
>  > from it?  Is your fix not applicable in general?  Does it have
>  > a downside that prevents you from applying it to vanilla Emacs?
> 
> Yes.  It's a complete rewrite of window resizing in Elisp.
> I hardly changed `fit-window-to-buffer', if at all.

I guess you are saying that that prevents your applying it to Emacs.  Or perhaps
that you don't yet think it is ready for that.

>  > I guess you are confirming that, so long as the binding 
>  > (e.g. to 1) is in effect, it will effectively always prevent
>  > window deletion?
> 
> No.  The let-binding just allows to make a window as small as one line
> in the first place.  But it does not prevent deleting a window.

Hm. The doc indicates that windows with fewer lines will not be deleted. And a
window cannot have fewer than 1 line (including the mode line). Perhaps the doc
needs to be corrected.

  "Allow deleting windows less than this tall....
   Emacs honors settings of this variable when enlarging
   or shrinking windows vertically."

Admittedly, saying that it allows deleting windows less than this tall is not
_exactly_ the same as saying that it disallows deleting windows taller than
this.  Still, the description strongly suggests something that is apparently
untrue.

> If you have a one line window and an nine lines window in a ten 
> lines frame and you want to enlarge the nine lines window by one
> line Emacs 23 will probably delete the one line window.

That sounds like a bug - it contradicts the doc.  Why shouldn't enlargement be
prevented instead, in that case?

>  > So my question still is: if `window-min-height' is 1, then 
>  > is deletion (due to enlarging or shrinking another window)
>  > always prevented?
> 
> No.
> 
>  > If not, what are the situations where such a binding is 
>  > not enough to prevent deletion?  And is there, for such
>  > situations, another good prevention recipe?
>  >
>  > I'm looking for good ways to deal practically with this 
>  > "misguided feature" as it manifests itself in
>  > `fit-window-to-buffer'.  Thx.
> 
> You can try to replace calls to `enlarge-window' by (appropriately
> configured) calls to `adjust-window-trailing-edge'.  Look at 
> the window balancing code to see how that can be done.

That's hardly what I would call a "good prevention recipe" or a "good way to
deal with this practically".  But thanks for the info.  At least I now know that
I'm not missing some simple solution.