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

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

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

I believe fit-window-to-buffer has become a bit upset and unnecessary
aggressive because of visual lines. It looks like it need a bit more
feedback from the display system to be really sure that the buffer is
entirely visible.

The attached patch is something I have used to get around the problem.
I am not sure it is the right thing but I am rather sure it does not
hurt.

Too see the problem it tries to fix just call the function with a
buffer larger than window and point below the window bottom (you have
to write a bit elisp code for that).

Of course we need a non-killing version of fit-window-to-buffer, but
for the moment this patch might be useful.

[-- Attachment #2: windows-less-aggressive-fit-1.diff --]
[-- Type: text/x-patch, Size: 612 bytes --]

=== modified file 'lisp/window.el'
--- trunk/lisp/window.el	2010-06-07 18:28:02 +0000
+++ patched/lisp/window.el	2010-06-09 18:48:37 +0000
@@ -1502,10 +1502,12 @@
 			     (forward-line 0))
 			   (point))))
 		(set-window-vscroll window 0)
+                (redisplay t)
 		(while (and (< desired-height max-height)
 			    (= desired-height (window-height))
 			    (not (pos-visible-in-window-p end)))
 		  (enlarge-window 1)
+                  (redisplay t)
 		  (setq desired-height (1+ desired-height))))
 	      ;; Return non-nil only if nothing "bad" happened.
 	      (setq value t)))

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

[martin rudalics]

 > I believe fit-window-to-buffer has become a bit upset and unnecessary
 > aggressive because of visual lines. It looks like it need a bit more
 > feedback from the display system to be really sure that the buffer is
 > entirely visible.
 >
 > The attached patch is something I have used to get around the problem.
 > I am not sure it is the right thing but I am rather sure it does not
 > hurt.

IIUC your change defeats the whole point of `pos-visible-in-window-p',
namely to calculate a position without doing a redisplay.  Worse even,
you might end up doing multiple redisplays within a loop.

TRT would be to handle the various line cases within `pos_visible_p'.
And obviously get rid of resizing windows within a loop.

 > Of course we need a non-killing version of fit-window-to-buffer, but
 > for the moment this patch might be useful.

What is a "non-killing version of fit-window-to-buffer"?

martin

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

[Lennart Borgman]

On Fri, Jun 11, 2010 at 3:21 PM, martin rudalics <rudalics@gmx.at> wrote:
>> I believe fit-window-to-buffer has become a bit upset and unnecessary
>> aggressive because of visual lines. It looks like it need a bit more
>> feedback from the display system to be really sure that the buffer is
>> entirely visible.
>>
>> The attached patch is something I have used to get around the problem.
>> I am not sure it is the right thing but I am rather sure it does not
>> hurt.
>
> IIUC your change defeats the whole point of `pos-visible-in-window-p',
> namely to calculate a position without doing a redisplay.

Yes, I know. I hoped someone had a better idea long term idea. Doing a
redisplay is just a quick fix.

What I saw was the even  2 lines high buffer made fit-window-to-buffer
delete sibling windows. All the time - but... I thought I knew how to
reproduce it. So I did not write any test procedures, I was just a bit
irritated. A mistake.


> Worse even,
> you might end up doing multiple redisplays within a loop.


Yes, I know. Maybe the first redisplay was all that was needed.


> TRT would be to handle the various line cases within `pos_visible_p'.


Thanks, I will leave this for the moment, but keep it in mind.


> And obviously get rid of resizing windows within a loop.
>
>> Of course we need a non-killing version of fit-window-to-buffer, but
>> for the moment this patch might be useful.
>
> What is a "non-killing version of fit-window-to-buffer"?


This function killed all other siblings even if it just actually needs
two lines if certain conditions are met. (Those I tried to describe.)

So this was just a desperate attempt to stop that. I do not know what
to do at the moment. I will try to reproduce this and look a bit
closer at it later.

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

[martin rudalics]

 > What I saw was the even  2 lines high buffer made fit-window-to-buffer
 > delete sibling windows. All the time - but... I thought I knew how to
 > reproduce it. So I did not write any test procedures, I was just a bit
 > irritated. A mistake.
[...]
 > This function killed all other siblings even if it just actually needs
 > two lines if certain conditions are met. (Those I tried to describe.)
 >
 > So this was just a desperate attempt to stop that. I do not know what
 > to do at the moment. I will try to reproduce this and look a bit
 > closer at it later.

Deleting other windows when resizing was a misguided feature.  I don't
do that any more for quite some time and didn't miss it yet ;-)

In any case, the issue whether a position is visible in a window is a
priori not related to the issue whether resizing is allowed to delete
any windows.  You patch might handle a few cases, accidentally ...

martin

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

[Lennart Borgman]

On Sat, Jun 12, 2010 at 10:00 AM, martin rudalics <rudalics@gmx.at> wrote:
>> What I saw was the even  2 lines high buffer made fit-window-to-buffer
>> delete sibling windows. All the time - but... I thought I knew how to
>> reproduce it. So I did not write any test procedures, I was just a bit
>> irritated. A mistake.
> [...]
>> This function killed all other siblings even if it just actually needs
>> two lines if certain conditions are met. (Those I tried to describe.)
>>
>> So this was just a desperate attempt to stop that. I do not know what
>> to do at the moment. I will try to reproduce this and look a bit
>> closer at it later.
>
> Deleting other windows when resizing was a misguided feature.  I don't
> do that any more for quite some time and didn't miss it yet ;-)

Did you rewrite fit-window-to-buffer or do you have another function for this?

> In any case, the issue whether a position is visible in a window is a
> priori not related to the issue whether resizing is allowed to delete
> any windows.  You patch might handle a few cases, accidentally ...

Yes, but what it handled was that it prevented a window to grow over
the buffers size.

But I do not know why the window grow bigger than the buffer. It is
just that after it happened to me ten times or so I throw in this
quick fix - and hoped that you had something more to say about it. If
I just had calmed down a bit and investigated it instead... ;-)

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

[martin rudalics]

 >> Deleting other windows when resizing was a misguided feature.  I don't
 >> do that any more for quite some time and didn't miss it yet ;-)
 >
 > Did you rewrite fit-window-to-buffer or do you have another function for this?

I wrote my own windows resizing functions mostly in Elisp.

 > Yes, but what it handled was that it prevented a window to grow over
 > the buffers size.

If your concern is that enlarging the window of a temporary buffer can
delete other windows then doing what you propose would handle just a few
cases.

 > But I do not know why the window grow bigger than the buffer.

The while loop at the end of `fit-window-to-buffer' is not sane.  Here I
still have it wrapped in a `condition-case' because in some pathological
cases it can throw an error.

martin

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

[Lennart Borgman]

On Sat, Jun 12, 2010 at 4:16 PM, martin rudalics <rudalics@gmx.at> wrote:
>>> Deleting other windows when resizing was a misguided feature.  I don't
>>> do that any more for quite some time and didn't miss it yet ;-)
>>
>> Did you rewrite fit-window-to-buffer or do you have another function for
>> this?
>
> I wrote my own windows resizing functions mostly in Elisp.
>
>> Yes, but what it handled was that it prevented a window to grow over
>> the buffers size.
>
> If your concern is that enlarging the window of a temporary buffer can
> delete other windows then doing what you propose would handle just a few
> cases.
>
>> But I do not know why the window grow bigger than the buffer.
>
> The while loop at the end of `fit-window-to-buffer' is not sane.  Here I
> still have it wrapped in a `condition-case' because in some pathological
> cases it can throw an error.


Can't we just throw in a better code instead of fit-window-to-buffer?
(And rename fit-window-to-buffer to killing-window-fit-to-buffer if
someone really wants it.)

It does not have to be perfect. Just good enough. We can surely make
it better later if we need to.

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

[Drew Adams]

> Deleting other windows when resizing was a misguided feature.

I'm very glad to hear you say that, sincerely.

> I don't do that any more for quite some time and didn't
> miss it yet ;-)

FWIW, I still see it happening in:

GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-06-07 on 3249CTO

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.

Is there a simple way to prevent deletion of other windows when using
`fit-window-to-buffer'? So far, I've just been let-binding `min-window-height'
to 1 around the call. Other suggestions welcome.

The use case of wanting to show as much of a buffer as possible without deleting
other windows in the frame, and also shrinking the window to the buffer size
when it can all be shown, has got to be a common use case.

Also, for the same type of buffer/window (typically a pop-up window such as
*Completions*), it would be good to have a simple way to make scrolling not show
half a window of blank space after the buffer text, when you scroll near the
buffer bottom. IOW, be able to have the end of the buffer act similarly to the
beginning: not have the window go beyond eob.

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

[martin rudalics]

 > Can't we just throw in a better code instead of fit-window-to-buffer?
 > (And rename fit-window-to-buffer to killing-window-fit-to-buffer if
 > someone really wants it.)
 >
 > It does not have to be perfect. Just good enough. We can surely make
 > it better later if we need to.

I suppose there's no need for a `killing-window-fit-to-buffer'.  Writing
a non-killing one with Emacs 23 means can be done in a number of ways:

(1) Use `adjust-window-trailing-edge'.  IIRC that's what you already did
     when you wrote your window balancing algorithm so you know how to do
     that.

(2) Save the window configuration and the number of windows around the
     `enlarge-window' call in `fit-window-to-buffer' and restore the
     configuration when a window got deleted.  That's more or less what
     `adjust-window-trailing-edge' does internally.

(3) Adjust enlarge_window so it doesn't delete windows.

Since I don't understand enlarge_window any more I can't give you advice
on (3).  If you want to try (1) or (2) ask me if you encounter problems.

martin

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

[martin rudalics]

 > Is there a simple way to prevent deletion of other windows when using
 > `fit-window-to-buffer'? So far, I've just been let-binding `min-window-height'
 > to 1 around the call. Other suggestions welcome.

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.

martin

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

[Drew Adams]

>  > Is there a simple way to prevent deletion of other windows 
>  > when using `fit-window-to-buffer'? So far, I've just been
>  > let-binding `min-window-height' to 1 around the call.
>  > Other suggestions welcome.
> 
> 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.

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?

What are your thoughts about let-binding `min-window-height'? What are the cases
where that won't fix the problem?

Thx.

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

[martin rudalics]

 > 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.

 > 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)
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.  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.

martin

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

[Lennart Borgman]

On Sun, Jun 13, 2010 at 4:34 PM, martin rudalics <rudalics@gmx.at> wrote:
>
> Please post a recipe for reproducing the problem.  I never had any
> problem with this in practice so I can't tell.
>
>> 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)
> 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.  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.

I am currently let-binding window-min-height to something smaller than
window-min-height, but I have never seen any problem because of that.

I think it is very practical to be able to do let-bind
window-min-height this way. I can look at the code of course and found
out, but where is is possible deleting of small height windows done?
Is there a thought behind it or is it a bug?

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

[Lennart Borgman]

On Sun, Jun 13, 2010 at 9:51 AM, martin rudalics <rudalics@gmx.at> wrote:
>> Can't we just throw in a better code instead of fit-window-to-buffer?
>> (And rename fit-window-to-buffer to killing-window-fit-to-buffer if
>> someone really wants it.)
>>
>> It does not have to be perfect. Just good enough. We can surely make
>> it better later if we need to.
>
> I suppose there's no need for a `killing-window-fit-to-buffer'.  Writing
> a non-killing one with Emacs 23 means can be done in a number of ways:
>
> (1) Use `adjust-window-trailing-edge'.  IIRC that's what you already did
>    when you wrote your window balancing algorithm so you know how to do
>    that.
>
> (2) Save the window configuration and the number of windows around the
>    `enlarge-window' call in `fit-window-to-buffer' and restore the
>    configuration when a window got deleted.  That's more or less what
>    `adjust-window-trailing-edge' does internally.
>
> (3) Adjust enlarge_window so it doesn't delete windows.
>
> Since I don't understand enlarge_window any more I can't give you advice
> on (3).  If you want to try (1) or (2) ask me if you encounter problems.

Thanks. Writing the code is probably not a big problem, keeping
another patch in my patched Emacs is. So I will write a new version
and send it here. (I wonder if I had not written it already and threw
it away to avoid keeping another patch.)

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

[Drew Adams]

>  > 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.

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

[martin rudalics]

 > I think it is very practical to be able to do let-bind
 > window-min-height this way. I can look at the code of course and found
 > out, but where is is possible deleting of small height windows done?

With the first call to delete_window in enlarge_window.  This deletes
the argument window if its new size is less than `window-min-height'.
And size_window calls delete_window on any window whose size has become
too small when (virtually) resizing a parent window back to its original
size.

 > Is there a thought behind it or is it a bug?

The thought behind it was probably that anyone who wants to enlarge a
window also accepts that other windows may get deleted in the process.
I suppose "collateral damage" has become the terminus technicus for such
behavior.

martin

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

[martin rudalics]

 >> 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.  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.

 > 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.

I can answer these questions as soon as you tell me your 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 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.  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.

 > 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.

martin

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

[Lennart Borgman]

On Sun, Jun 13, 2010 at 7:44 PM, martin rudalics <rudalics@gmx.at> wrote:
>> I think it is very practical to be able to do let-bind
>> window-min-height this way. I can look at the code of course and found
>> out, but where is is possible deleting of small height windows done?
>
> With the first call to delete_window in enlarge_window.  This deletes
> the argument window if its new size is less than `window-min-height'.
> And size_window calls delete_window on any window whose size has become
> too small when (virtually) resizing a parent window back to its original
> size.

Thanks.

>> Is there a thought behind it or is it a bug?
>
> The thought behind it was probably that anyone who wants to enlarge a
> window also accepts that other windows may get deleted in the process.
> I suppose "collateral damage" has become the terminus technicus for such
> behavior.

;-)

Is there consensus that we should get rid of this kind deleting of
windows with height less than window-min-height?

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.

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

[Stefan Monnier]

>   "Allow deleting windows less than this tall....
>    Emacs honors settings of this variable when enlarging
>    or shrinking windows vertically."
[...]
>> 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?

If you read the above docstring carefully, you'll see that it doesn't
say "don't make windows smaller than that" but just that if a window
gets smaller it'll be deleted.

I do think it's a misfeature, but it's not one that's trivial to fix.
IIUC Martin has worked on a fix, but he hasn't submitted it yet, so
I guess it's not quite ready for prime time.


        Stefan

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

[martin rudalics]

 > 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.

So far I don't have the slightest idea what "the problem" is.  I don't
even know which window gets deleted: The one showing the buffer whose
window shall be fit (in which case it would be interesting to know
whether the window shall be shrunk or enlarged), or another window.

 >> 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?

It's prevented in `adjust-window-trailing-edge'.  For `enlarge-window'
there's no such rule.  The latter's doc-string clearly states:

   "This function can delete windows if they get too small."

martin

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

[Drew Adams]

> which window gets deleted: The one showing the buffer whose
> window shall be fit (in which case it would be interesting to know
> whether the window shall be shrunk or enlarged), or another window.

I thought I made it clear that another window is deleted from the window being
fit:

 "I want that window to fit its buffer as much as possible,
  but without deleting any other windows."

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

[martin rudalics]

 > Of course we need a non-killing version of fit-window-to-buffer, but
 > for the moment this patch might be useful.

`fit-window-to-buffer' doesn't kill windows any more so this issue
should have been resolved.

martin