GNU bug report logs -
#46718
27.1; truncate-lines in minibuffer prevents auto resize
Previous Next
Reported by: Clemens <clemera <at> posteo.net>
Date: Tue, 23 Feb 2021 13:45:01 UTC
Severity: normal
Found in version 27.1
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46718 in the body.
You can then email your comments to 46718 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#46718
; Package
emacs
.
(Tue, 23 Feb 2021 13:45:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Clemens <clemera <at> posteo.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 23 Feb 2021 13:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
in Selectrum we are using an overlay after-string to display completion
candidates within the minibuffer. We also want to truncate-lines to
prevent wrapping for long lines. When using:
;; 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#46718
; Package
emacs
.
(Wed, 24 Feb 2021 15:50:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 46718 <at> debbugs.gnu.org (full text, mbox):
> From: Clemens <clemera <at> posteo.net>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#46718
; Package
emacs
.
(Wed, 24 Feb 2021 16:07:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 46718 <at> debbugs.gnu.org (full text, mbox):
> 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 sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Wed, 24 Feb 2021 16:35:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Clemens <clemera <at> posteo.net>
:
bug acknowledged by developer.
(Wed, 24 Feb 2021 16:35:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 46718-done <at> debbugs.gnu.org (full text, mbox):
> Cc: 46718 <at> debbugs.gnu.org
> From: Clemens <clemera <at> posteo.net>
> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 25 Mar 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.