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

["Drew Adams" <drew.adams@oracle.com>]

>  > There doesn't seem to be a problem before Emacs 23. Maybe 
>  > there is a problem, theoretically, but I haven't
>  > encountered one. What about returning to the pre-23 code?
> 
> 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.

I have not seen that problem arise in releases before Emacs 23, personally.  The
code (e.g. for `fit-window-to-buffer') was changed considerably in Emacs 23.  I
have supposed that at least part of that code change introduced this "misguided
feature".  Perhaps I'm mistaken about that, but as I say, I do see no such
problem prior to Emacs 23.

Were you involved with the code changes for this from Emacs 22 to 23?  Did those
changes in fact introduce this "misguided feature", or was it already present?  

As I say, I myself see no such "misguided feature" manifest itself prior to 23.
Even if the "misguided feature" is theoretically present also before 23, in my
own, practical experience it shows up only with Emacs 23.

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?

>  > What are your thoughts about let-binding 
>  > `min-window-height'?  What are the cases
>  > where that won't fix the problem?
> 
> Let-binding `window-min-height' (I suppose that's the variable you mean)

Yes, that's the variable I meant.

> can be used to make a window less than `window-min-height' 
> high.  Doing this can eventually cause the deletion of that
> window after the binding has been exited.

Obviously, if it is only that binding that prevents its deletion, then when the
binding is no longer in effect nothing will prevent its deletion.

As I said, I'm interested in the context of a popup window such as
*Completions*.  I want that window to fit its buffer as much as possible, but
without deleting any other windows.  Such a window has limited lifespan; when it
is deleted the other windows will naturally reclaim the space, and the variable
will no longer be bound (e.g. to 1).

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?  That was my
question.  I wondered if this was always the case or if there were some cases
where it did not hold.

> This is not a speciality of `fit-window-to-buffer' but
> a consequence of the fact that Emacs can delete windows that 
> are smaller than `window-min-height' high.

It is the prevention that I'm interested in.  Whether the code causing the
problem is in `fit-window-to-buffer' itself or elsewhere is not very important
to me.  The problem manifests itself for me when I use `fit-window-to-buffer'.
It might also manifest itself for others in other contexts (dunno), but it is
`fit-window-to-buffer' that is, in effect, problematic for me (in Emacs 23+).

So my question still is: if `window-min-height' is 1, then is deletion (due to
enlarging or shrinking another window) always prevented?

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.