GNU bug report logs - #46718
27.1; truncate-lines in minibuffer prevents auto resize

Previous Next

Full log

Message #8 received at 46718 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clemens <clemera <at> posteo.net>
Cc: 46718 <at> debbugs.gnu.org
Subject: Re: bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize
Date: Wed, 24 Feb 2021 17:49:22 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.