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

[martin rudalics]

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

Then the "old windows" below ...

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

... are such permanent windows that should not get resized by
'display-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;

This one should shrink only if the window is either new or has a
'quit-restore' parameter that passes the

            (and (eq (car quit-restore) 'same)
                 (eq (nth 1 quit-restore) 'window)))

test.  In either case, it will ignore any user supplied
'window-height' option.

> - in vc-diff-finish.

This should probably do a similar thing.

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

Wouldn't just (window-height) suffice?

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

IIUC 'vc-log-internal-common' fills the buffer after popping to it so
I cannot see a way to simply accommodate that.

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

We could introduce a new ALIST argument, say 'pre-display-function'.
The function specified there would be called before running the body
of 'window--display-buffer'.  In the case at hand, that function would
fill the buffer so OT1H 'shrink-window-if-larger-than-buffer' would
know the real buffer size and OTOH a 'window-height' entry would allow
to override that.  I wouldn't know whether and how to suitably pass
any arguments to such a function, though.

martin