unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / Atom feed
* bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize
@ 2021-02-23 13:44 Clemens
  2021-02-24 15:49 ` Eli Zaretskii
  0 siblings, 1 reply; 4+ messages in thread
From: Clemens @ 2021-02-23 13:44 UTC (permalink / raw)
  To: 46718

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.






^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize
  2021-02-23 13:44 bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize Clemens
@ 2021-02-24 15:49 ` Eli Zaretskii
  2021-02-24 16:05   ` Clemens
  0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2021-02-24 15:49 UTC (permalink / raw)
  To: Clemens; +Cc: 46718

> From: Clemens <clemera@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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize
  2021-02-24 15:49 ` Eli Zaretskii
@ 2021-02-24 16:05   ` Clemens
  2021-02-24 16:34     ` Eli Zaretskii
  0 siblings, 1 reply; 4+ messages in thread
From: Clemens @ 2021-02-24 16:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 46718

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






^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize
  2021-02-24 16:05   ` Clemens
@ 2021-02-24 16:34     ` Eli Zaretskii
  0 siblings, 0 replies; 4+ messages in thread
From: Eli Zaretskii @ 2021-02-24 16:34 UTC (permalink / raw)
  To: Clemens; +Cc: 46718-done

> Cc: 46718@debbugs.gnu.org
> From: Clemens <clemera@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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-02-24 16:34 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-23 13:44 bug#46718: 27.1; truncate-lines in minibuffer prevents auto resize Clemens
2021-02-24 15:49 ` Eli Zaretskii
2021-02-24 16:05   ` Clemens
2021-02-24 16:34     ` Eli Zaretskii

unofficial mirror of bug-gnu-emacs@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-bugs/0 emacs-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-bugs emacs-bugs/ https://yhetil.org/emacs-bugs \
		bug-gnu-emacs@gnu.org
	public-inbox-index emacs-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.bugs
	nntp://news.gmane.io/gmane.emacs.bugs


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git