[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#39822: 27.0.90; Cannot set *Completions* buffer height using display-buffer-alist
Date: Sun, 15 Mar 2020 18:49:35 +0100

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


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]