Re: [PATCH] completions-max-height

[Ergus <spacibba@aol.com>]

On Tue, Mar 08, 2022 at 02:29:10PM +0100, Ergus wrote:
>On Tue, Mar 08, 2022 at 08:47:13AM +0000, Philip Kaludercic wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>>I understand your intention, but in practice making this more complex
>>>is useless. The mini buffer is always down and making the completions
>>>to move somewhere else is uncomfortable and may require more
>>>lisp/emacs knowledge to change the default behavior from the
>>>user. Which is completely the opposite to my intention. Actually this
>>>same result may be reached with an advise as I discussed on yesterday
>>>on emacs help. But a simple custom is better.
>>>
>>>I am totally fine if you propose something else more general if that don't forces the user to write a function to change a simple height.
>>
>>What I proposed would just require something like
>>
>>   (setq completion-display-buffer-option '(display-buffer-at-bottom (window-height . 10)))
>>
>
>This just works:
>
>(setq display-buffer-alist '(("^\\*Completions\\*$" .
>			      (display-buffer-at-bottom
>			       (window-height . 10)))))
>
>For the simplest case this works... But there is not a way to handle the
>conditionals without affecting some users. For example when using inline
>completion or the ones using resize-temp-buffer-window
>
>We can use a function instead, but in that case the user customization
>may need a more complex approach instead of just a setq.
>
>Maybe a better lisper could propose something better that allows to set
>this without a defun, an advise or defining a tricky alist that may
>conflict with something else?
>
>
After a day with this config I found several issues.

At the end it required to do:

(add-to-list 'display-buffer-alist
	     '("^\\*Completions\\*$" .
	       ((display-buffer--maybe-same-window
		display-buffer-reuse-window
		display-buffer--maybe-pop-up-frame)
		(window-height . 10))))

Otherwise many things happen (completions buffer replication for not
reusing window, not popup frames and so on.)

So at the end I think that the initial patch is the best simpler
approach (the code could be simplified even more by a better lisper
probably) because otherwise the user may need do a complex config for a
most simple need, creating conflicts and changing some of the default
behaviors...

Simple is better than complex.
Complex is better than complicated.

Best,
Ergus