23.0.60; Resizing may delete windows

23.0.60; Resizing may delete windows

[Lennart Borgman (gmail)]

Michael Kifer wrote:
 > OK, I see it. It is an emacs bug. If you have windows that are <
 > window-min-height then it deletes such windows if you de-maximize
 > the emacs window.
 >
 > To see this, maximize a window and do
 >
 > (let ((window-min-height 1)) (split-window-vertically 2))
 >
 > Then make this window normal size and see what happens.

Ok, thanks Michael. The upper window disappears for me too so it looks 
like a bug in Emacs and not a bug in ediff.

(Tested with Emacs 23 from today.)

	

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 >  > To see this, maximize a window and do
 >  >
 >  > (let ((window-min-height 1)) (split-window-vertically 2))
 >  >
 >  > Then make this window normal size and see what happens.

This doesn't show anything.  `window-min-height' can have any value when
the "make this window normal size" happens.  Unfortunately, doing

(progn
   (setq window-min-height 1)
   (split-window nil 2))

in a maximized frame with one window and subsequently demaximizing the
frame gets me an upper window with one line and without a modeline which
clearly _is_ a bug.  Maybe that's even the bug you've seen.

Earlier I avoided a similar bug by introducing the `safe_min_size'
thingy in `size_window'.  In the special case this test fails because
`window_min_size_2' can't tell anything useful for non-leaf windows.
When demaximizing the frame Emacs does

         new_sizes = shrink_windows (total, size, nchildren, n, min_size,
                                     resize_fixed_p, *forward, width_p);

with min_size 1 since the modeline is not counted for the root window.
If I subsequently either refuse to shrink the one-text-line-window or do
delete it, the precalculation done by shrink_windows apparently gets
confused and I'm left with a messy frame.  A workaround is

         new_sizes = shrink_windows (total, size, nchildren, n, 2,
                                     resize_fixed_p, *forward, width_p);

which seems safe both for minimum height and width values.  Calling
`window_min_size_2' within `shrink_windows', on the other hand, appears
non-trivial.

Jan?

Re: 23.0.60; Resizing may delete windows

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  >  > To see this, maximize a window and do
>  >  >
>  >  > (let ((window-min-height 1)) (split-window-vertically 2))
>  >  >
>  >  > Then make this window normal size and see what happens.
> 
> This doesn't show anything.  `window-min-height' can have any value when
> the "make this window normal size" happens.  Unfortunately, doing

You mean it happens async?

> (progn
>   (setq window-min-height 1)
>   (split-window nil 2))
> 
> in a maximized frame with one window and subsequently demaximizing the
> frame gets me an upper window with one line and without a modeline which
> clearly _is_ a bug.  Maybe that's even the bug you've seen.

Maybe, but in that case I have seen another one too. The layout when I 
first saw this was:

xxxxxxxxx
x   x   x
x   x   x
x   x   x
xxxxxxxxx
x       x
xxxxxxxxx

Three windows. The bottom 1-line window disappeared. (This was in ediff 
with the control panel in the same frame.)

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 >>  >  > To see this, maximize a window and do
 >>  >  >
 >>  >  > (let ((window-min-height 1)) (split-window-vertically 2))
 >>  >  >
 >>  >  > Then make this window normal size and see what happens.
 >>
 >> This doesn't show anything.  `window-min-height' can have any value when
 >> the "make this window normal size" happens.  Unfortunately, doing
 >
 >
 > You mean it happens async?

I don't understand.  In your example you bind `window-min-height' to 1
only while you split the window.  When you resize the frame the binding
is not effective - presumably the top-level value is used instead.

 > Maybe, but in that case I have seen another one too. The layout when I
 > first saw this was:
 >
 > xxxxxxxxx
 > x   x   x
 > x   x   x
 > x   x   x
 > xxxxxxxxx
 > x       x
 > xxxxxxxxx
 >
 > Three windows. The bottom 1-line window disappeared. (This was in ediff
 > with the control panel in the same frame.)

Yes, but in general the ediff frame is not maximized when it's created,
hence people usually won't see that.  I suppose you somehow managed to
start with a maximized frame and a one-text-line control panel.  When
you de-maximize that frame the shrinking mechanism may remove the
control panel window provided `window-min-height' evals to the standard
value 4.

Setting `window-min-height' to 1 when the window wants a modeline is
asking for trouble and the documentation should say so.  However Emacs
should handle this case gracefully.

Re: 23.0.60; Resizing may delete windows

[Lennart Borgman (gmail)]

martin rudalics wrote:
> I don't understand.  In your example you bind `window-min-height' to 1
> only while you split the window.  When you resize the frame the binding
> is not effective - presumably the top-level value is used instead.

Eh, yes. sorry.

>  > Maybe, but in that case I have seen another one too. The layout when I
>  > first saw this was:
>  >
>  > xxxxxxxxx
>  > x   x   x
>  > x   x   x
>  > x   x   x
>  > xxxxxxxxx
>  > x       x
>  > xxxxxxxxx
>  >
>  > Three windows. The bottom 1-line window disappeared. (This was in ediff
>  > with the control panel in the same frame.)
> 
> Yes, but in general the ediff frame is not maximized when it's created,
> hence people usually won't see that.  I suppose you somehow managed to
> start with a maximized frame and a one-text-line control panel.

That is just how ediff starts with a maximized frame and the control 
panel in the same frame as the buffers you use ediff on.

> When
> you de-maximize that frame the shrinking mechanism may remove the
> control panel window provided `window-min-height' evals to the standard
> value 4.

"may remove" - are you suggesting this is not a bug? Or are you just 
saying you see that the code is written that way?

> Setting `window-min-height' to 1 when the window wants a modeline is
> asking for trouble and the documentation should say so.  However Emacs
> should handle this case gracefully.

Yes. But I am a little bit sorry for having mixed this trouble with the 
one I actually saw in ediff. Anyway it is of course very good that you 
are taking care of the window-min-height=1 problem.

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 >> When
 >> you de-maximize that frame the shrinking mechanism may remove the
 >> control panel window provided `window-min-height' evals to the standard
 >> value 4.
 >
 >
 > "may remove" - are you suggesting this is not a bug?

The doc-string of `window-min-height' states

*Delete any window less than this tall (including its mode line).
The value is in line units.

Hence it's certainly not a bug.

 > Or are you just
 > saying you see that the code is written that way?

Not "or" but "and".  IIUC Jan tried to handle this in a way that small
windows are preserved.  Either he doesn't succeed always or the idea of
setting `window-min-height' to 1 gets in his way.

 >> Setting `window-min-height' to 1 when the window wants a modeline is
 >> asking for trouble and the documentation should say so.  However Emacs
 >> should handle this case gracefully.
 >
 > Yes. But I am a little bit sorry for having mixed this trouble with the
 > one I actually saw in ediff.

Your way of reproducing the problem was flawed.  It took me some time to
understand what you meant.  I suggest you set `window-min-height'
buffer-locally to 2 in the ediff control panel and look what happens
when the frame gets resized.  If the window still goes away we have a
bug.

 > Anyway it is of course very good that you
 > are taking care of the window-min-height=1 problem.

One aspect that puzzles me is why, when `window-min-height' equals 1,
Emacs doesn't simply display the window's modeline.  This way we could
simply shrink a window to its modeline and expand it whenever we need it
again.

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 :-(

Re: 23.0.60; Resizing may delete windows

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  > "may remove" - are you suggesting this is not a bug?
> 
> The doc-string of `window-min-height' states
> 
> *Delete any window less than this tall (including its mode line).
> The value is in line units.
> 
> Hence it's certainly not a bug.

I am not sure I agree. It does not say under what conditions it can 
delete that window.

I think the conditions should be specified in the doc string. And I do 
not think that the conditions should embrace the case with ediff. There 
is simply no need to delete that window during resizing.

>  > Or are you just
>  > saying you see that the code is written that way?
> 
> Not "or" but "and".  IIUC Jan tried to handle this in a way that small
> windows are preserved.  Either he doesn't succeed always or the idea of
> setting `window-min-height' to 1 gets in his way.

Thanks.

> Your way of reproducing the problem was flawed.  It took me some time to
> understand what you meant.

Sorry, I know.

> I suggest you set `window-min-height'
> buffer-locally to 2 in the ediff control panel and look what happens
> when the frame gets resized.  If the window still goes away we have a
> bug.

Thanks, that cures the problem.

Michael, could you please add that? (And please make the control panel 
window dedicated during ediff. It really is not useful for something 
else then ;-) )

> One aspect that puzzles me is why, when `window-min-height' equals 1,
> Emacs doesn't simply display the window's modeline.  This way we could
> simply shrink a window to its modeline and expand it whenever we need it
> again.

That would be much better than a disappearing mode line.

> 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 :-(

Another good point. I think this is really what users expect, at least I 
did.

Re: 23.0.60; Resizing may delete windows

[Michael Kifer]

> > I suggest you set `window-min-height'
> > buffer-locally to 2 in the ediff control panel and look what happens
> > when the frame gets resized.  If the window still goes away we have a
> > bug.
> 
> Thanks, that cures the problem.
> 
> Michael, could you please add that?

OK. However, I do think that deleting windows just like that is too
aggressive and counter-intuitive.

> (And please make the control panel 
> window dedicated during ediff. It really is not useful for something 
> else then ;-) )

No, dedicated windows in frames that have other windows are too troublesome.
They often surprise the user.

That little ediff window does not need to be dedicated, since nothing else
gets into it unless you try hard :-)
And if this happens then it is easy to recover.

> > 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 :-(


But when you maximize then the little window does not get deleted - it just
gets bigger. It is better to resize a window than to completely delete it.

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > No, dedicated windows in frames that have other windows are too troublesome.
 > They often surprise the user.

Yes, unfortunately.  IIRC Stefan once wanted to introduce various
degrees of dedicatedness ...

 > That little ediff window does not need to be dedicated, since nothing else
 > gets into it unless you try hard :-)
 > And if this happens then it is easy to recover.
 >
 >
 >>>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 :-(
 >
 > But when you maximize then the little window does not get deleted - it just
 > gets bigger. It is better to resize a window than to completely delete it.

The idea of my proposal was just to keep the height of the control panel
fixed during frame size changes.  Personally, I would prefer some soft
fixedness here which would prevent a window from getting implicitly
resized whenever the window layout changes.

Re: 23.0.60; Resizing may delete windows

[Lennart Borgman (gmail)]

Michael Kifer wrote:
>>> I suggest you set `window-min-height'
>>> buffer-locally to 2 in the ediff control panel and look what happens
>>> when the frame gets resized.  If the window still goes away we have a
>>> bug.
>> Thanks, that cures the problem.
>>
>> Michael, could you please add that?
> 
> OK. However, I do think that deleting windows just like that is too
> aggressive and counter-intuitive.

Thanks. Yes, it really looks like that.

>> (And please make the control panel 
>> window dedicated during ediff. It really is not useful for something 
>> else then ;-) )
> 
> No, dedicated windows in frames that have other windows are too troublesome.
> They often surprise the user.

What is the problem? I do not understand. That little window just exists 
when ediff is active on that frame, right?

> That little ediff window does not need to be dedicated, since nothing else
> gets into it unless you try hard :-)

If you use Emacs client then new files are opened in the ediff control 
window.

Re: 23.0.60; Resizing may delete windows

[Michael Kifer]

> > No, dedicated windows in frames that have other windows are too troublesome.
> > They often surprise the user.
> 
> What is the problem? I do not understand. That little window just exists 
> when ediff is active on that frame, right?

The problem is that there are too many situations when ediff has to
remember to undedicate or delete that window if the user decides to
postpone the work and do something else.

> > That little ediff window does not need to be dedicated, since nothing else
> > gets into it unless you try hard :-)
> 
> If you use Emacs client then new files are opened in the ediff control 
> window.

Then use multiframe setup :-)

Just dedicating that small window does not work. Too much stuff needs to be
taken care of. I'll take another look though.

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> > No, dedicated windows in frames that have other windows are too
>> > troublesome.  They often surprise the user.
>> 
>> What is the problem? I do not understand. That little window just exists 
>> when ediff is active on that frame, right?

> The problem is that there are too many situations when ediff has to
> remember to undedicate or delete that window if the user decides to
> postpone the work and do something else.

I still don't understand: why should ediff have to undedicate
that window?  Or why should it need to delete it: if it's dedicated
it'll be deleted automatically when the buffer is killed.


        Stefan

Re: 23.0.60; Resizing may delete windows

[Michael Kifer]

> >> > No, dedicated windows in frames that have other windows are too
> >> > troublesome.  They often surprise the user.
> >> 
> >> What is the problem? I do not understand. That little window just exists 
> >> when ediff is active on that frame, right?
> 
> > The problem is that there are too many situations when ediff has to
> > remember to undedicate or delete that window if the user decides to
> > postpone the work and do something else.
> 
> I still don't understand: why should ediff have to undedicate
> that window?  Or why should it need to delete it: if it's dedicated
> it'll be deleted automatically when the buffer is killed.

There are cases when ediff can be suspended. In that case the small window
should be deleted. There are cases when several ediff sessions are active
at the same time. Doing all this properly with dedicated windows seems too
much trouble with little payoff. But, as I said, I'll take another look to
see if this can be done without major complications.


	--michael 

> 
> 
>         Stefan
> 

Re: 23.0.60; Resizing may delete windows

[Lennart Borgman (gmail)]

Michael Kifer wrote:
>>>>> No, dedicated windows in frames that have other windows are too
>>>>> troublesome.  They often surprise the user.
>>>> What is the problem? I do not understand. That little window just exists 
>>>> when ediff is active on that frame, right?
>>> The problem is that there are too many situations when ediff has to
>>> remember to undedicate or delete that window if the user decides to
>>> postpone the work and do something else.
>> I still don't understand: why should ediff have to undedicate
>> that window?  Or why should it need to delete it: if it's dedicated
>> it'll be deleted automatically when the buffer is killed.
> 
> There are cases when ediff can be suspended. In that case the small window
> should be deleted. There are cases when several ediff sessions are active
> at the same time. Doing all this properly with dedicated windows seems too
> much trouble with little payoff. But, as I said, I'll take another look to
> see if this can be done without major complications.


The documentation for set-window-dedicated-p says that the dedicated 
window will not display any other buffer than the one it currently displays.

Does ediff really use that little window to display other buffers? 
Otherwise it looks to me that there should be no problem just making 
that little window dedicated.

(BTW, why does the function name has "-p" at the end?)

Re: 23.0.60; Resizing may delete windows

[Michael Kifer]

> > There are cases when ediff can be suspended. In that case the small window
> > should be deleted. There are cases when several ediff sessions are active
> > at the same time. Doing all this properly with dedicated windows seems too
> > much trouble with little payoff. But, as I said, I'll take another look to
> > see if this can be done without major complications.
> 
> 
> The documentation for set-window-dedicated-p says that the dedicated 
> window will not display any other buffer than the one it currently displays.
> 
> Does ediff really use that little window to display other buffers? 
> Otherwise it looks to me that there should be no problem just making 
> that little window dedicated.

This has to do with the heuristics that ediff uses when it decides how to
place buffers in the multiframe setup. As I said, I'll see if there is a
simple way to make the control window dedicated without complicating those
heuristics.

> (BTW, why does the function name has "-p" at the end?)

No idea. (Not my fault. :)


	--michael  

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> I still don't understand: why should ediff have to undedicate
>> that window?  Or why should it need to delete it: if it's dedicated
>> it'll be deleted automatically when the buffer is killed.

> There are cases when ediff can be suspended.  In that case the small
> window should be deleted. There are cases when several ediff sessions
> are active at the same time.  Doing all this properly with dedicated
> windows seems too much trouble with little payoff.

I can't think of any way that the above situations would have any impact
on or be impacted by the use of a dedicated window for ediff's
control buffer.

> But, as I said, I'll take another look to see if this can be done
> without major complications.

Please do, and please tell us of any problem you encounter,


        Stefan

Dedicated windows (was: 23.0.60; Resizing may delete windows)

[Stefan Monnier]

>> (And please make the control panel window dedicated during ediff. It
>> really is not useful for something else then ;-) )

> No, dedicated windows in frames that have other windows are too troublesome.
> They often surprise the user.

Sounds like a bug (or at least a misfeature).  Could you give us
some details?


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 >> The doc-string of `window-min-height' states
 >>
 >> *Delete any window less than this tall (including its mode line).
 >> The value is in line units.
 >>
 >> Hence it's certainly not a bug.
 >
 > I am not sure I agree. It does not say under what conditions it can
 > delete that window.

It may happen whenever you create or resize any window on the associated
frame as I understood from the code.  The doc-string doesn't help much
in this sense - you simply have to wait for the worst :-(

 > I think the conditions should be specified in the doc string. And I do
 > not think that the conditions should embrace the case with ediff. There
 > is simply no need to delete that window during resizing.

That's what `window-min-height' is for.  Setting it to 2 globally should
avoid that any window with a modeline gets deleted during resizing.

Re: 23.0.60; Resizing may delete windows

[Lennart Borgman (gmail)]

martin rudalics wrote:
>  >> The doc-string of `window-min-height' states
>  >>
>  >> *Delete any window less than this tall (including its mode line).
>  >> The value is in line units.
>  >>
>  >> Hence it's certainly not a bug.
>  >
>  > I am not sure I agree. It does not say under what conditions it can
>  > delete that window.
> 
> It may happen whenever you create or resize any window on the associated
> frame as I understood from the code.  The doc-string doesn't help much
> in this sense - you simply have to wait for the worst :-(
> 
>  > I think the conditions should be specified in the doc string. And I do
>  > not think that the conditions should embrace the case with ediff. There
>  > is simply no need to delete that window during resizing.
> 
> That's what `window-min-height' is for.  Setting it to 2 globally should
> avoid that any window with a modeline gets deleted during resizing.

The please make 2 the default.

Re: 23.0.60; Resizing may delete windows

[Richard Stallman]

    > That's what `window-min-height' is for.  Setting it to 2 globally should
    > avoid that any window with a modeline gets deleted during resizing.

    The please make 2 the default.

That would be a bad default in my opinion.
It is inconvenient for users if a window gets that small.
The default value for `window-min-height' avoids that
inconvenience.

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > That would be a bad default in my opinion.
 > It is inconvenient for users if a window gets that small.
 > The default value for `window-min-height' avoids that
 > inconvenience.

The default value for `window-min-height' asserts that the window may
get deleted in that case.  Do you think that auto-deleting a window is
more convenient than making it that small?

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

> The doc-string of `window-min-height' states

> *Delete any window less than this tall (including its mode line).
> The value is in line units.

> Hence it's certainly not a bug.

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

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

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


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > 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.  If it doesn't we have a bug to fix.  If it
does we might reconsider the default values.

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

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

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

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

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

Certainly not to 1 because the comment in `set-window-text-height' tells
me

       ;; Setting window-min-height to a value like 1 can lead to very
       ;; bizarre displays because it also allows Emacs to make *other*
       ;; windows 1-line tall, which means that there's no more space for
       ;; the modeline.

but I probably wouldn't mind setting them to 2.  Rather keep a window of
height 2 and resize it when needed than have Emacs delete it.

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>       ;; Setting window-min-height to a value like 1 can lead to very
>       ;; bizarre displays because it also allows Emacs to make *other*
>       ;; windows 1-line tall, which means that there's no more space for
>       ;; the modeline.

> but I probably wouldn't mind setting them to 2.  Rather keep a window of
> height 2 and resize it when needed than have Emacs delete it.

But if Emacs can always resist the temptation to delete a window of size 2,
surely it can resist the temptation to delete one of size 3 (or more)?


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > But if Emacs can always resist the temptation to delete a window of size 2,
 > surely it can resist the temptation to delete one of size 3 (or more)?

If Emacs can confuse me surely you can confuse me more.

When I set `window-min-height' to 3 Emacs is allowed to auto-delete
windows that are 1 or 2 lines tall.  When I set this to 2 Emacs may
auto-delete one-line windows only.  Hence, if I want to safely prevent
auto-deletion I set this to the lowest value that doesn't "lead to
bizarre displays" namely 2.  Then Emacs will resist any temptations to
delete my larger-than-one-line windows and I might live happily.  What
am I missing?

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> But if Emacs can always resist the temptation to delete a window of size 2,
>> surely it can resist the temptation to delete one of size 3 (or more)?

> If Emacs can confuse me surely you can confuse me more.

> When I set `window-min-height' to 3 Emacs is allowed to auto-delete
> windows that are 1 or 2 lines tall.  When I set this to 2 Emacs may
> auto-delete one-line windows only.  Hence, if I want to safely prevent
> auto-deletion I set this to the lowest value that doesn't "lead to
> bizarre displays" namely 2.  Then Emacs will resist any temptations to
> delete my larger-than-one-line windows and I might live happily.  What
> am I missing?

I do not think that window-min-height should mean "do your best to shoot
windows as soon as they're silly enough to fall below this threshold".

As long as the user does not explicitly change the size of this precise
window (but instead resizes the whole frame, for example, or resizes
some other window), Emacs should do its best to avoid making the window
smaller than that threshold (so that it doesn't delete it).


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > I do not think that window-min-height should mean "do your best to shoot
 > windows as soon as they're silly enough to fall below this threshold".

I don't understand shrink_windows enough to make it less trigger-happy.
 From the code I only understand that a high value of `window-min-height'
is an invitation to shoot silly windows.

 > As long as the user does not explicitly change the size of this precise
 > window (but instead resizes the whole frame, for example, or resizes
 > some other window), Emacs should do its best to avoid making the window
 > smaller than that threshold (so that it doesn't delete it).

This thread started with an example where a window's height was
explicitly set to a value smaller than the top-level value of that
threshold.  How should Emacs deal with that?  How should Emacs deal with
`gnus-window-min-height' or `emerge-one-line-window'?

In another thread people discuss perspectives a la Eclipse.  How should
Emacs handle one- or two-lines windows in such "perspectives" when
changing the window configuration?  Should perspectives avoid one-line
windows?  Should Emacs be allowed to auto-delete them?

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> I do not think that window-min-height should mean "do your best to shoot
>> windows as soon as they're silly enough to fall below this threshold".

> I don't understand shrink_windows enough to make it less trigger-happy.
> From the code I only understand that a high value of `window-min-height'
> is an invitation to shoot silly windows.

Yes, that's indeed how it works now.  But it would be good to change it
a bit.  And I agree that it's not easy code.

>> As long as the user does not explicitly change the size of this precise
>> window (but instead resizes the whole frame, for example, or resizes
>> some other window), Emacs should do its best to avoid making the window
>> smaller than that threshold (so that it doesn't delete it).

> This thread started with an example where a window's height was
> explicitly set to a value smaller than the top-level value of that
> threshold.  How should Emacs deal with that?  How should Emacs deal with
> `gnus-window-min-height' or `emerge-one-line-window'?

Indeed, this is even more tricky, but in my opinion the right behavior
is to enforce window-min-height only when a window is
shrunk explicitly or created.  When a window is resized as part of some
other resize (e.g. frame-resize), then the window should only be deleted
if we can't preserve its size.

> In another thread people discuss perspectives a la Eclipse.  How should
> Emacs handle one- or two-lines windows in such "perspectives" when
> changing the window configuration?  Should perspectives avoid one-line
> windows?  Should Emacs be allowed to auto-delete them?

Those windows should have their window-min-height set to some different
value, I guess.


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 >>I don't understand shrink_windows enough to make it less trigger-happy.
 >>From the code I only understand that a high value of `window-min-height'
 >>is an invitation to shoot silly windows.
 >
 > Yes, that's indeed how it works now.  But it would be good to change it
 > a bit.  And I agree that it's not easy code.

I suppose that `shrink_windows' simply has to take into account the
presence of modelines when checking the min_size of windows.  That's
quite tedious to do - I have to alloc a second vector to store the
minimum sizes of all involved windows.

 >>This thread started with an example where a window's height was
 >>explicitly set to a value smaller than the top-level value of that
 >>threshold.  How should Emacs deal with that?  How should Emacs deal with
 >>`gnus-window-min-height' or `emerge-one-line-window'?
 >
 > Indeed, this is even more tricky, but in my opinion the right behavior
 > is to enforce window-min-height only when a window is
 > shrunk explicitly or created.  When a window is resized as part of some
 > other resize (e.g. frame-resize), then the window should only be deleted
 > if we can't preserve its size.

Agreed if "if we can't preserve its size" is read as "if we cannot
establish the new frame-size by other means".

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>>> I don't understand shrink_windows enough to make it less trigger-happy.
>>> From the code I only understand that a high value of `window-min-height'
>>> is an invitation to shoot silly windows.
>> Yes, that's indeed how it works now.  But it would be good to change it
>> a bit.  And I agree that it's not easy code.
> I suppose that `shrink_windows' simply has to take into account the
> presence of modelines when checking the min_size of windows.  That's
> quite tedious to do - I have to alloc a second vector to store the
> minimum sizes of all involved windows.

I can't think of any reason why the modelines would matter.  Just, when
rearranging windows because of a change somewhere (frame size or
other-window size), try hard not to shrink a window (i.e. prefer
shrinking another window) if that shrinkage would cause it to
be deleted.

> Agreed if "if we can't preserve its size" is read as "if we cannot
> establish the new frame-size by other means".

That's right.


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 >>I suppose that `shrink_windows' simply has to take into account the
 >>presence of modelines when checking the min_size of windows.  That's
 >>quite tedious to do - I have to alloc a second vector to store the
 >>minimum sizes of all involved windows.
 >
 > I can't think of any reason why the modelines would matter.

FWIW, because shrink_windows and the rest of window.c have different
conceptions of what min_size is: shrink_windows considers a window of
height 2 as resizable to 1 (because min_size equals 1).  All other
functions either delete a window of height 1 or don't allow to resize it
to 1 if the window wants a modeline.

 > Just, when
 > rearranging windows because of a change somewhere (frame size or
 > other-window size), try hard not to shrink a window (i.e. prefer
 > shrinking another window) if that shrinkage would cause it to
 > be deleted.

That's what I meant - I have to teach shrink_windows not to ask for
resizing windows of height 2.

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>>> I suppose that `shrink_windows' simply has to take into account the
>>> presence of modelines when checking the min_size of windows.  That's
>>> quite tedious to do - I have to alloc a second vector to store the
>>> minimum sizes of all involved windows.
>> 
>> I can't think of any reason why the modelines would matter.

> FWIW, because shrink_windows and the rest of window.c have different
> conceptions of what min_size is: shrink_windows considers a window of
> height 2 as resizable to 1 (because min_size equals 1).  All other
> functions either delete a window of height 1 or don't allow to resize it
> to 1 if the window wants a modeline.

>> Just, when
>> rearranging windows because of a change somewhere (frame size or
>> other-window size), try hard not to shrink a window (i.e. prefer
>> shrinking another window) if that shrinkage would cause it to
>> be deleted.

> That's what I meant - I have to teach shrink_windows not to ask for
> resizing windows of height 2.

I'm not sure I understand what you mean: window-min-(height|width) is
a variable.  Where do you get your constants from?


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > I'm not sure I understand what you mean: window-min-(height|width) is
 > a variable.  Where do you get your constants from?

The only constants in this context are MIN_SAFE_WINDOW_(HEIGHT|WIDTH).
window-min-(height|width) are variables the user can try to set.  If
they are less than MIN_SAFE_WINDOW_(HEIGHT|WIDTH) check_min_window_sizes
will reset them.  And, in window_min_size_2 I check them again to not
produce a new height or width that would omit the modeline or
scroll-bars if these shall be shown.

BTW, since I've been just looking at window.c from XEmacs.  They have

/* The smallest acceptable dimensions for a window.  Anything smaller
    might crash Emacs.  */
#define MIN_SAFE_WINDOW_WIDTH  (2)
#define MIN_SAFE_WINDOW_HEIGHT (2)

which, by virtue of brute force, would eliminate our problems as well.

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> I'm not sure I understand what you mean: window-min-(height|width) is
>> a variable.  Where do you get your constants from?

> The only constants in this context are MIN_SAFE_WINDOW_(HEIGHT|WIDTH).
> window-min-(height|width) are variables the user can try to set.  If
> they are less than MIN_SAFE_WINDOW_(HEIGHT|WIDTH) check_min_window_sizes
> will reset them.  And, in window_min_size_2 I check them again to not
> produce a new height or width that would omit the modeline or
> scroll-bars if these shall be shown.

Right, but in your message you referred to 1 and 2, rather than to
window-min-(height|width).  As far as I can tell, we're discussing
window resizing which is only affected by window-min-(height|width).
MIN_SAFE_WINDOW_(HEIGHT|WIDTH) only affect window-min-(height|width), so
it only affects resizing in a very indirect manner (e.g. we can scan
all windows, reset window-min-(height|width) to valid values and the
resize without paying attention to MIN_SAFE_WINDOW_(HEIGHT|WIDTH)).

> /* The smallest acceptable dimensions for a window.  Anything smaller
>    might crash Emacs.  */
> #define MIN_SAFE_WINDOW_WIDTH  (2)
> #define MIN_SAFE_WINDOW_HEIGHT (2)

> which, by virtue of brute force, would eliminate our problems as well.

Yes, but I do use 1-line-high windows, and disallowing them just because
we can't be bothered to write the window-resize code in the right way
isn't the right answer.


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > Right, but in your message you referred to 1 and 2, rather than to
 > window-min-(height|width).  As far as I can tell, we're discussing
 > window resizing which is only affected by window-min-(height|width).
 > MIN_SAFE_WINDOW_(HEIGHT|WIDTH) only affect window-min-(height|width), so
 > it only affects resizing in a very indirect manner (e.g. we can scan
 > all windows, reset window-min-(height|width) to valid values and the
 > resize without paying attention to MIN_SAFE_WINDOW_(HEIGHT|WIDTH)).

shrink_windows is called with a min_size argument of 1 if shrinking
heights.  That's all I can observe.  The bug goes away when I call it
with min_size 2.

 > Yes, but I do use 1-line-high windows, and disallowing them just because
 > we can't be bothered to write the window-resize code in the right way
 > isn't the right answer.

That's why shrink_windows would have to check for every window whether
it has a modeline and not resize it if it has one and its actual height
is 2.

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> Right, but in your message you referred to 1 and 2, rather than to
>> window-min-(height|width).  As far as I can tell, we're discussing
>> window resizing which is only affected by window-min-(height|width).
>> MIN_SAFE_WINDOW_(HEIGHT|WIDTH) only affect window-min-(height|width), so
>> it only affects resizing in a very indirect manner (e.g. we can scan
>> all windows, reset window-min-(height|width) to valid values and the
>> resize without paying attention to MIN_SAFE_WINDOW_(HEIGHT|WIDTH)).

> shrink_windows is called with a min_size argument of 1 if shrinking
> heights.  That's all I can observe.

When I put a breakpoint on shrink_windows, I see it gets called with
a min_size of 4 (and width_p is 0).  I.e. it gets called with the value
of window-min-height, just as it should.

>> Yes, but I do use 1-line-high windows, and disallowing them just because
>> we can't be bothered to write the window-resize code in the right way
>> isn't the right answer.

> That's why shrink_windows would have to check for every window whether
> it has a modeline and not resize it if it has one and its actual height
> is 2.

I still do not understand what modelines have to do with it.


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > When I put a breakpoint on shrink_windows, I see it gets called with
 > a min_size of 4 (and width_p is 0).  I.e. it gets called with the value
 > of window-min-height, just as it should.

There's no bug with `window-min-height' equalling 4.  But what happens
when you set `window-min-height' to 1?  That was the original scenario
we discussed.

 > I still do not understand what modelines have to do with it.

Please try with `window-min-height' 1.

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> When I put a breakpoint on shrink_windows, I see it gets called with
>> a min_size of 4 (and width_p is 0).  I.e. it gets called with the value
>> of window-min-height, just as it should.

> There's no bug with `window-min-height' equalling 4.  But what happens
> when you set `window-min-height' to 1?

I don't know, you tell me.

>> I still do not understand what modelines have to do with it.
> Please try with `window-min-height' 1.

I see no difference (probably because my windows are large anyway).


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 >>Please try with `window-min-height' 1.
 >
 > I see no difference (probably because my windows are large anyway).

There are two problems.  The OP's complaint had

(let ((window-min-height 1))
   (split-window-vertically 2))

with the emanating one-text-line window disappearing when the frame was
resized (de-maximized).  I proposed to work around the first problem by
setting `window-min-height' to 2.  If you could reproduce this and find
out where and why shrink_windows wants to delete this window, it might
be probably easy to find a solution.

Working around the first problem by setting `window-min-height' to 1 as

(progn
   (setq window-min-height 1)
   (split-window nil 2))

exhibits a second problem, namely that resizing the frame may get me the
emanating one-text-line window without a modeline.  I can fix that
second problem by calling shrink_windows as

         new_sizes = shrink_windows (total, size, nchildren, n, 2,
                                     resize_fixed_p, *forward, width_p);

which has the, possibly unwanted, side-effect that a window without
modeline cannot be shrunk (by shrink_windows) to a height of 1.

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>>> Please try with `window-min-height' 1.
>> I see no difference (probably because my windows are large anyway).

> There are two problems.  The OP's complaint had

> (let ((window-min-height 1))
>   (split-window-vertically 2))

> with the emanating one-text-line window disappearing when the frame was
> resized (de-maximized).  I proposed to work around the first problem by
> setting `window-min-height' to 2.  If you could reproduce this and find
> out where and why shrink_windows wants to delete this window, it might
> be probably easy to find a solution.

It probably wants to delete the window because somewhere it (needlessly)
tries to resize it (to a smaller size, probably) and then checks the
size and decides to delete.  The problem is right there: not in any of
the settings of window-min-height.


        Stefan

Re: 23.0.60; Resizing may delete windows

[martin rudalics]

 > It probably wants to delete the window because somewhere it (needlessly)
 > tries to resize it (to a smaller size, probably) and then checks the
 > size and decides to delete.  The problem is right there: not in any of
 > the settings of window-min-height.

Consider the following stretch from enlarge_window:

	  /* Add delta1 lines or columns to this window, and to the parent,
	     keeping things consistent while not affecting siblings.  */
	  XSETINT (CURSIZE (parent), opht + delta1);
	  (*setsizefun) (window, XINT (*sizep) + delta1, 0);

	  /* Squeeze out delta1 lines or columns from our parent,
	     shriking this window and siblings proportionately.
	     This brings parent back to correct size.
	     Delta1 was calculated so this makes this window the desired size,
	     taking it all out of the siblings.  */
	  (*setsizefun) (parent, opht, 0);

It calls size_window in the hope that size_window

(i) does not reduce the height of "this window", and

(ii) implicitly removes windows that have become "to small".


Now consider the code for changing the size of a frame: It eventually
winds up calling something like

	  set_window_height (FRAME_ROOT_WINDOW (f),
			     (newheight
			      - 1
			      - FRAME_TOP_MARGIN (f)),
			      0);

in the hope that size_window

(i) does not delete windows when they become "to small", as long as

(ii) there's at least one larger window it can steal lines from.


So it seems we want to eat our cake and have it too.

Re: 23.0.60; Resizing may delete windows

[Stefan Monnier]

>> It probably wants to delete the window because somewhere it (needlessly)
>> tries to resize it (to a smaller size, probably) and then checks the
>> size and decides to delete.  The problem is right there: not in any of
>> the settings of window-min-height.

> Consider the following stretch from enlarge_window:

> 	  /* Add delta1 lines or columns to this window, and to the parent,
> 	     keeping things consistent while not affecting siblings.  */
> 	  XSETINT (CURSIZE (parent), opht + delta1);
> 	  (*setsizefun) (window, XINT (*sizep) + delta1, 0);

> 	  /* Squeeze out delta1 lines or columns from our parent,
> 	     shriking this window and siblings proportionately.
> 	     This brings parent back to correct size.
> 	     Delta1 was calculated so this makes this window the desired size,
> 	     taking it all out of the siblings.  */
> 	  (*setsizefun) (parent, opht, 0);

> It calls size_window in the hope that size_window

> (i) does not reduce the height of "this window", and

> (ii) implicitly removes windows that have become "to small".


> Now consider the code for changing the size of a frame: It eventually
> winds up calling something like

> 	  set_window_height (FRAME_ROOT_WINDOW (f),
> 			     (newheight
> 			      - 1
> 			      - FRAME_TOP_MARGIN (f)),
> 			      0);

> in the hope that size_window

> (i) does not delete windows when they become "to small", as long as

> (ii) there's at least one larger window it can steal lines from.

> So it seems we want to eat our cake and have it too.

Yes, fixing the behavior with the current code is problematic.
We probably need to rethink/reimplement the window-resize code to
fix it.


        Stefan