* 23.0.60; Resizing may delete windows @ 2008-03-21 20:59 Lennart Borgman (gmail) 2008-03-25 16:27 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-21 20:59 UTC (permalink / raw) To: emacs-pretest-bug, Michael Kifer 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.) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-21 20:59 23.0.60; Resizing may delete windows Lennart Borgman (gmail) @ 2008-03-25 16:27 ` martin rudalics 2008-03-25 17:21 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-03-25 16:27 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: emacs-pretest-bug, Jan D., Michael Kifer > > 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? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-25 16:27 ` martin rudalics @ 2008-03-25 17:21 ` Lennart Borgman (gmail) 2008-03-25 18:57 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-25 17:21 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-pretest-bug, Jan D., Michael Kifer 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.) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-25 17:21 ` Lennart Borgman (gmail) @ 2008-03-25 18:57 ` martin rudalics 2008-03-25 20:11 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-03-25 18:57 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: emacs-pretest-bug, Jan D., Michael Kifer >> > > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-25 18:57 ` martin rudalics @ 2008-03-25 20:11 ` Lennart Borgman (gmail) 2008-03-25 22:10 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-25 20:11 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-pretest-bug, Jan D., Michael Kifer 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-25 20:11 ` Lennart Borgman (gmail) @ 2008-03-25 22:10 ` martin rudalics 2008-03-25 22:54 ` Lennart Borgman (gmail) 2008-03-26 1:55 ` Stefan Monnier 0 siblings, 2 replies; 42+ messages in thread From: martin rudalics @ 2008-03-25 22:10 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: emacs-pretest-bug, Jan D., Michael Kifer >> 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 :-( ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-25 22:10 ` martin rudalics @ 2008-03-25 22:54 ` Lennart Borgman (gmail) 2008-03-26 6:34 ` Michael Kifer 2008-03-26 7:38 ` 23.0.60; Resizing may delete windows martin rudalics 2008-03-26 1:55 ` Stefan Monnier 1 sibling, 2 replies; 42+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-25 22:54 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-pretest-bug, Jan D., Michael Kifer 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-25 22:54 ` Lennart Borgman (gmail) @ 2008-03-26 6:34 ` Michael Kifer 2008-03-26 7:48 ` martin rudalics ` (2 more replies) 2008-03-26 7:38 ` 23.0.60; Resizing may delete windows martin rudalics 1 sibling, 3 replies; 42+ messages in thread From: Michael Kifer @ 2008-03-26 6:34 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: martin rudalics, Jan D., emacs-pretest-bug > > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 6:34 ` Michael Kifer @ 2008-03-26 7:48 ` martin rudalics 2008-03-26 9:38 ` Lennart Borgman (gmail) 2008-03-26 14:12 ` Dedicated windows (was: 23.0.60; Resizing may delete windows) Stefan Monnier 2 siblings, 0 replies; 42+ messages in thread From: martin rudalics @ 2008-03-26 7:48 UTC (permalink / raw) To: Michael Kifer; +Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail) > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 6:34 ` Michael Kifer 2008-03-26 7:48 ` martin rudalics @ 2008-03-26 9:38 ` Lennart Borgman (gmail) 2008-03-26 13:53 ` Michael Kifer 2008-03-26 14:12 ` Dedicated windows (was: 23.0.60; Resizing may delete windows) Stefan Monnier 2 siblings, 1 reply; 42+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-26 9:38 UTC (permalink / raw) To: Michael Kifer; +Cc: martin rudalics, Jan D., emacs-pretest-bug 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 9:38 ` Lennart Borgman (gmail) @ 2008-03-26 13:53 ` Michael Kifer 2008-03-26 20:52 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: Michael Kifer @ 2008-03-26 13:53 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: martin rudalics, Jan D., emacs-pretest-bug > > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 13:53 ` Michael Kifer @ 2008-03-26 20:52 ` Stefan Monnier 2008-03-26 18:53 ` Michael Kifer 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-03-26 20:52 UTC (permalink / raw) To: Michael Kifer Cc: martin rudalics, Jan D., Lennart Borgman (gmail), emacs-pretest-bug >> > 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 20:52 ` Stefan Monnier @ 2008-03-26 18:53 ` Michael Kifer 2008-03-27 0:02 ` Lennart Borgman (gmail) 2008-03-27 2:17 ` Stefan Monnier 0 siblings, 2 replies; 42+ messages in thread From: Michael Kifer @ 2008-03-26 18:53 UTC (permalink / raw) To: Stefan Monnier Cc: martin rudalics, Jan D., Lennart Borgman (gmail), emacs-pretest-bug > >> > 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 > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 18:53 ` Michael Kifer @ 2008-03-27 0:02 ` Lennart Borgman (gmail) 2008-03-27 2:23 ` Michael Kifer 2008-03-27 2:17 ` Stefan Monnier 1 sibling, 1 reply; 42+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-27 0:02 UTC (permalink / raw) To: Michael Kifer; +Cc: martin rudalics, Jan D., Stefan Monnier, emacs-pretest-bug 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?) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-27 0:02 ` Lennart Borgman (gmail) @ 2008-03-27 2:23 ` Michael Kifer 0 siblings, 0 replies; 42+ messages in thread From: Michael Kifer @ 2008-03-27 2:23 UTC (permalink / raw) To: Lennart Borgman (gmail) Cc: martin rudalics, Jan D., Stefan Monnier, emacs-pretest-bug > > 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 18:53 ` Michael Kifer 2008-03-27 0:02 ` Lennart Borgman (gmail) @ 2008-03-27 2:17 ` Stefan Monnier 1 sibling, 0 replies; 42+ messages in thread From: Stefan Monnier @ 2008-03-27 2:17 UTC (permalink / raw) To: Michael Kifer Cc: martin rudalics, Jan D., Lennart Borgman (gmail), emacs-pretest-bug >> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Dedicated windows (was: 23.0.60; Resizing may delete windows) 2008-03-26 6:34 ` Michael Kifer 2008-03-26 7:48 ` martin rudalics 2008-03-26 9:38 ` Lennart Borgman (gmail) @ 2008-03-26 14:12 ` Stefan Monnier 2 siblings, 0 replies; 42+ messages in thread From: Stefan Monnier @ 2008-03-26 14:12 UTC (permalink / raw) To: Michael Kifer Cc: martin rudalics, Jan D., Lennart Borgman (gmail), emacs-pretest-bug >> (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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-25 22:54 ` Lennart Borgman (gmail) 2008-03-26 6:34 ` Michael Kifer @ 2008-03-26 7:38 ` martin rudalics 2008-03-26 9:32 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-03-26 7:38 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: emacs-pretest-bug, Jan D., Michael Kifer >> 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 7:38 ` 23.0.60; Resizing may delete windows martin rudalics @ 2008-03-26 9:32 ` Lennart Borgman (gmail) 2008-03-26 22:26 ` Richard Stallman 0 siblings, 1 reply; 42+ messages in thread From: Lennart Borgman (gmail) @ 2008-03-26 9:32 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-pretest-bug, Jan D., Michael Kifer 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 9:32 ` Lennart Borgman (gmail) @ 2008-03-26 22:26 ` Richard Stallman 2008-03-27 7:48 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Richard Stallman @ 2008-03-26 22:26 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: rudalics, jan.h.d, kifer, emacs-pretest-bug > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 22:26 ` Richard Stallman @ 2008-03-27 7:48 ` martin rudalics 0 siblings, 0 replies; 42+ messages in thread From: martin rudalics @ 2008-03-27 7:48 UTC (permalink / raw) To: rms; +Cc: emacs-pretest-bug, jan.h.d, Lennart Borgman (gmail), kifer > 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? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-25 22:10 ` martin rudalics 2008-03-25 22:54 ` Lennart Borgman (gmail) @ 2008-03-26 1:55 ` Stefan Monnier 2008-03-26 7:40 ` martin rudalics 1 sibling, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-03-26 1:55 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer > 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 1:55 ` Stefan Monnier @ 2008-03-26 7:40 ` martin rudalics 2008-03-26 14:25 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-03-26 7:40 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 7:40 ` martin rudalics @ 2008-03-26 14:25 ` Stefan Monnier 2008-03-26 17:11 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-03-26 14:25 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 14:25 ` Stefan Monnier @ 2008-03-26 17:11 ` martin rudalics 2008-03-26 20:54 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-03-26 17:11 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >>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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 17:11 ` martin rudalics @ 2008-03-26 20:54 ` Stefan Monnier 2008-03-26 22:30 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-03-26 20:54 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer > ;; 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 20:54 ` Stefan Monnier @ 2008-03-26 22:30 ` martin rudalics 2008-03-27 2:22 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-03-26 22:30 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer > 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? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-26 22:30 ` martin rudalics @ 2008-03-27 2:22 ` Stefan Monnier 2008-03-27 7:50 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-03-27 2:22 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-27 2:22 ` Stefan Monnier @ 2008-03-27 7:50 ` martin rudalics 2008-03-29 3:48 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-03-27 7:50 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer > 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? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-27 7:50 ` martin rudalics @ 2008-03-29 3:48 ` Stefan Monnier 2008-04-02 8:43 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-03-29 3:48 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-03-29 3:48 ` Stefan Monnier @ 2008-04-02 8:43 ` martin rudalics 2008-04-02 14:52 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-04-02 8:43 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >>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". ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-02 8:43 ` martin rudalics @ 2008-04-02 14:52 ` Stefan Monnier 2008-04-02 17:04 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-04-02 14:52 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >>> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-02 14:52 ` Stefan Monnier @ 2008-04-02 17:04 ` martin rudalics 2008-04-03 13:56 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-04-02 17:04 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >>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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-02 17:04 ` martin rudalics @ 2008-04-03 13:56 ` Stefan Monnier 2008-04-03 14:43 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-04-03 13:56 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >>> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-03 13:56 ` Stefan Monnier @ 2008-04-03 14:43 ` martin rudalics 2008-04-03 15:03 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-04-03 14:43 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-03 14:43 ` martin rudalics @ 2008-04-03 15:03 ` Stefan Monnier 2008-04-03 15:19 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-04-03 15:03 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-03 15:03 ` Stefan Monnier @ 2008-04-03 15:19 ` martin rudalics 2008-04-03 20:52 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-04-03 15:19 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-03 15:19 ` martin rudalics @ 2008-04-03 20:52 ` Stefan Monnier 2008-04-03 21:47 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-04-03 20:52 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-03 20:52 ` Stefan Monnier @ 2008-04-03 21:47 ` martin rudalics 2008-04-03 22:16 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-04-03 21:47 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-03 21:47 ` martin rudalics @ 2008-04-03 22:16 ` Stefan Monnier 2008-04-04 6:55 ` martin rudalics 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2008-04-03 22:16 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-03 22:16 ` Stefan Monnier @ 2008-04-04 6:55 ` martin rudalics 2008-04-04 14:02 ` Stefan Monnier 0 siblings, 1 reply; 42+ messages in thread From: martin rudalics @ 2008-04-04 6:55 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >>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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 23.0.60; Resizing may delete windows 2008-04-04 6:55 ` martin rudalics @ 2008-04-04 14:02 ` Stefan Monnier 0 siblings, 0 replies; 42+ messages in thread From: Stefan Monnier @ 2008-04-04 14:02 UTC (permalink / raw) To: martin rudalics Cc: emacs-pretest-bug, Jan D., Lennart Borgman (gmail), Michael Kifer >>> 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2008-04-04 14:02 UTC | newest] Thread overview: 42+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-03-21 20:59 23.0.60; Resizing may delete windows Lennart Borgman (gmail) 2008-03-25 16:27 ` martin rudalics 2008-03-25 17:21 ` Lennart Borgman (gmail) 2008-03-25 18:57 ` martin rudalics 2008-03-25 20:11 ` Lennart Borgman (gmail) 2008-03-25 22:10 ` martin rudalics 2008-03-25 22:54 ` Lennart Borgman (gmail) 2008-03-26 6:34 ` Michael Kifer 2008-03-26 7:48 ` martin rudalics 2008-03-26 9:38 ` Lennart Borgman (gmail) 2008-03-26 13:53 ` Michael Kifer 2008-03-26 20:52 ` Stefan Monnier 2008-03-26 18:53 ` Michael Kifer 2008-03-27 0:02 ` Lennart Borgman (gmail) 2008-03-27 2:23 ` Michael Kifer 2008-03-27 2:17 ` Stefan Monnier 2008-03-26 14:12 ` Dedicated windows (was: 23.0.60; Resizing may delete windows) Stefan Monnier 2008-03-26 7:38 ` 23.0.60; Resizing may delete windows martin rudalics 2008-03-26 9:32 ` Lennart Borgman (gmail) 2008-03-26 22:26 ` Richard Stallman 2008-03-27 7:48 ` martin rudalics 2008-03-26 1:55 ` Stefan Monnier 2008-03-26 7:40 ` martin rudalics 2008-03-26 14:25 ` Stefan Monnier 2008-03-26 17:11 ` martin rudalics 2008-03-26 20:54 ` Stefan Monnier 2008-03-26 22:30 ` martin rudalics 2008-03-27 2:22 ` Stefan Monnier 2008-03-27 7:50 ` martin rudalics 2008-03-29 3:48 ` Stefan Monnier 2008-04-02 8:43 ` martin rudalics 2008-04-02 14:52 ` Stefan Monnier 2008-04-02 17:04 ` martin rudalics 2008-04-03 13:56 ` Stefan Monnier 2008-04-03 14:43 ` martin rudalics 2008-04-03 15:03 ` Stefan Monnier 2008-04-03 15:19 ` martin rudalics 2008-04-03 20:52 ` Stefan Monnier 2008-04-03 21:47 ` martin rudalics 2008-04-03 22:16 ` Stefan Monnier 2008-04-04 6:55 ` martin rudalics 2008-04-04 14:02 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.