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

[Juri Linkov <juri@linkov.net>]

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