[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32825: 27.0.50; Deterministic window management
From: |
Juri Linkov |
Subject: |
bug#32825: 27.0.50; Deterministic window management |
Date: |
Mon, 05 Nov 2018 23:49:27 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>>> (1) Decide whether a specific window can be (re-)used. Should we
>>> refute it when the window cannot be enlarged to 'min-height' lines?
>>> The decision would have to be made via 'window-resizable-p' and its
>>> IGNORE argument set to the window itself so we can, for example,
>>> (re-)use a preserved size window showing some other buffer.
>>>
>>> (2) Actually resize that window via a 'window-height' entry. This is
>>> independent from (1). Processing a 'window-height' entry is just some
>>> sort of bonus work 'display-buffer' does for the convenience of the
>>> user. It in now way affects the decision which window is chosen.
>>>
>>> So please think of any bad consequences of what we decide in (1) like
>>> not using _any_ window on the selected frame because none of them fits
>>> the 'min-height' constraint. Consider a default two windows frame
>>> where the size of the selected window is preserved.
>>
>> Maybe simply display the buffer in the below window regardless of its
>> size? Because it makes no sense for display-buffer-below-selected to
>> display the buffer in a window other than below.
>
> But then the same argument holds for popping up a new window. Even
> if we can't make the new window as large as we want, popping it up
> below the selected one is the only thing that makes sense if the
> selected window is at the bottom of the frame. Unless we decide that
> failing should be better than not making the window high enough.
Maybe I misunderstand something, but I see that already everything is
working fine. When I tried with display-buffer-below-selected
to cause an error in a narrow buffer at the bottom of the frame,
then the *Backtrace* buffer is displayed in a new window created
by horizontal splitting of the largest window on the frame.
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/01
- bug#32825: 27.0.50; Deterministic window management, Juri Linkov, 2018/11/01
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/02
- bug#32825: 27.0.50; Deterministic window management, Juri Linkov, 2018/11/03
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/04
- bug#32825: 27.0.50; Deterministic window management, Juri Linkov, 2018/11/04
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/05
- bug#32825: 27.0.50; Deterministic window management,
Juri Linkov <=
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/06
- bug#32825: 27.0.50; Deterministic window management, Juri Linkov, 2018/11/06
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/07
- bug#32825: 27.0.50; Deterministic window management, Juri Linkov, 2018/11/07
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/08
- bug#32825: 27.0.50; Deterministic window management, Juri Linkov, 2018/11/08
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/09
- bug#32825: 27.0.50; Deterministic window management, Michael Heerdegen, 2018/11/09
- bug#32825: 27.0.50; Deterministic window management, martin rudalics, 2018/11/09
- bug#32825: 27.0.50; Deterministic window management, Juri Linkov, 2018/11/10