bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize

Eli Zaretskii
> From: Clemens <[hidden email]>
> Date: Tue, 23 Feb 2021 14:44:20 +0100
>
> ;; emacs -Q
> (setq resize-mini-windows t)
> (minibuffer-with-setup-hook
>      (lambda ()
>        (setq-local truncate-lines t)
>        (let ((ov (make-overlay (point-max) (point-max)))
>    (minibuf-after-string " \nOne\nTwo\nThree"))
> (put-text-property 0 1 'cursor t minibuf-after-string)
> (overlay-put ov 'after-string minibuf-after-string)))
>    (read-string ":"))
>
> the mini window will not resize but when commenting out the setting for
> truncate-lines it resizes appropriately.

This is (was) not supported.  When truncate-lines is non-nil in the
minibuffer, Emacs assumed the minibuffer text is just one line.  And I
can understand that assumption: frankly, setting truncate-lines with
multi-line text in the minibuffer makes little sense, because it means
some of the text will not be shown, something that contradicts the
very purpose of resizing the mini-window.  Why would someone do
something weird like that?

Anyway, I've made this work as expected on the master branch now.



Reply | Threaded
Open this post in threaded view
|

bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize

Clemens
> This is (was) not supported.  When truncate-lines is non-nil in the
> minibuffer, Emacs assumed the minibuffer text is just one line.  And I
> can understand that assumption: frankly, setting truncate-lines with
> multi-line text in the minibuffer makes little sense, because it means
> some of the text will not be shown, something that contradicts the
> very purpose of resizing the mini-window.  Why would someone do
> something weird like that?
>
> Anyway, I've made this work as expected on the master branch now.

I understand the assumption, makes sense when not considering such weird
use cases as we might have in Selectrum ;) In Selectrum candidates are
shown vertically stacked, we additionally ensure that candidates are a
single line. It works pretty well and makes a lot of things easier to
deal with in our UI. Thanks for adding this!




Reply | Threaded
Open this post in threaded view
|

bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize

Eli Zaretskii
> Cc: [hidden email]
> From: Clemens <[hidden email]>
> Date: Wed, 24 Feb 2021 17:05:59 +0100
>
> I understand the assumption, makes sense when not considering such weird
> use cases as we might have in Selectrum ;) In Selectrum candidates are
> shown vertically stacked, we additionally ensure that candidates are a
> single line. It works pretty well and makes a lot of things easier to
> deal with in our UI. Thanks for adding this!

You are welcome.

Closing.