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

[martin rudalics <rudalics@gmx.at>]

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