bug#39822: 27.0.90; Cannot set *Completions* buffer height using display-buffer-alist

[martin rudalics <rudalics@gmx.at>]

 > These calls should remain in 'window--display-buffer' to adjust the
 > window height afterwards.

Yes.

 >> But what if a function like 'dired-format-columns-of-files' wanted to
 >>
 >> (1) know the width of the window used for displaying the buffer,
 >
 > 'dired-format-columns-of-files' is called when the window
 > is already displayed, so it can find the width of the window,
 > and it uses 'completion--insert-strings' for that, see below.

Does it know the window for sure?  Always think of the case where the
buffer is already displayed in some other window.

 >> (2) according to that (presumably fixed) width adjust columns, establish
 >> a maximum width of buffer lines or do something else width related,
 >
 > Same as above.
 >
 >> (3) leave it to 'window--display-buffer' to adjust the window height
 >> afterwards?
 >
 > It already allows 'window--display-buffer' to adjust the window height
 > afterwards in the previous patch.
 >
 >> And be able to do (1)-(3) in the orthogonal direction, that is, base (2)
 >> on a presumably fixed window height?
 >
 > You mean to not allow adjusting the window height afterwards?
 > Then the call of 'display-buffer' should be without alist entries
 > 'window-height' and 'preserve-size'.

We have to be always prepared for the case that a split happens in the
orthogonal direction.

 > The current implementation doesn't supply the window, and
 > 'dired-format-columns-of-files' and 'minibuffer-completion-help'
 > use 'completion--insert-strings':
 >
 > 	   (window (get-buffer-window (current-buffer) 0))

That's precisely what I'm afraid of (and it happens in a dozen other
cases in our code base as well, IIRC).  Better make sure now that we
always act on the window returned by 'display-buffer'.

 > 	   (wwidth (if window (1- (window-width window)) 79))
 >
 > Do you propose to rewrite 'completion--insert-strings' for accept a new
 > argument 'window'?  Or to rely on the fact that the displayed window should
 > be already selected by its caller?  Will this break backward-compatibility
 > for packages that use it?

Maybe it's overkill but I'd give 'completion--insert-strings' an
additional window argument.

martin