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

[martin rudalics]

> 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