bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36859: Customizable fit-window-to-buffer


From: Juri Linkov
Subject: bug#36859: Customizable fit-window-to-buffer
Date: Wed, 31 Jul 2019 23:57:14 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

>> It's a nice feature when fit-window-to-buffer resizes temporary windows
>> that go away after exiting the minibuffer.
>>
>> OTOH, resizing permanent windows does more harm, because these windows
>> can be reused later for other buffers, but their size remains too narrow.
>
> What is a permanent window?

A window that remains indefinitely after finishing the current command,
and where other buffers with different number of lines might appear.

                               IIRC we only fit new windows or frames
> that go away when quit and carefully try to not resize other windows
> but the one used for splitting off the new window.  Old windows are
> fit iff they did show the same buffer before and were created for that
> buffer.  Such windows should, by concept, not be reused for showing
> another buffer.

I see that the existing windows are resized with
'shrink-window-if-larger-than-buffer'.  So not only
'fit-window-to-buffer' is involved.

Two examples of 'shrink-window-if-larger-than-buffer':
- in vc-log-internal-common;
- in vc-diff-finish.

>> I'm not asking to change the default behavior, but it should be customizable.
>
> In what sense?

I hope it would be possible to specify a special action alist entry
in 'display-buffer-alist' , e.g.

  (window-height . no-fit-window)

to override

  (window-height . fit-window-to-buffer)

This requires that more commands should use this alist in their
'display-buffer' calls instead of directly calling
'shrink-window-if-larger-than-buffer'.

Do you think this is feasible?  If not, then maybe these commands
should provide post-display hooks such as e.g. 'proced-post-display-hook'
where 'fit-window-to-buffer' is added by default, but can be removed
by customization.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]