From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown Date: Wed, 18 Dec 2019 18:31:48 +0200 Message-ID: <83sglh3897.fsf@gnu.org> References: <86r211sy6b.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="868"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38645@debbugs.gnu.org To: ynyaaa@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 18 17:36:06 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ihcIv-0018Hl-LT for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Dec 2019 17:36:05 +0100 Original-Received: from localhost ([::1]:57010 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihcIt-0006j9-QD for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Dec 2019 11:36:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42765) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihcG0-0002v3-9Z for bug-gnu-emacs@gnu.org; Wed, 18 Dec 2019 11:33:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihcFy-0007xT-Pw for bug-gnu-emacs@gnu.org; Wed, 18 Dec 2019 11:33:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37861) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ihcFy-0007vO-KD for bug-gnu-emacs@gnu.org; Wed, 18 Dec 2019 11:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ihcFy-000617-Em for bug-gnu-emacs@gnu.org; Wed, 18 Dec 2019 11:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Dec 2019 16:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38645 X-GNU-PR-Package: emacs Original-Received: via spool by 38645-submit@debbugs.gnu.org id=B38645.157668673023044 (code B ref 38645); Wed, 18 Dec 2019 16:33:02 +0000 Original-Received: (at 38645) by debbugs.gnu.org; 18 Dec 2019 16:32:10 +0000 Original-Received: from localhost ([127.0.0.1]:43830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ihcF7-0005zc-PD for submit@debbugs.gnu.org; Wed, 18 Dec 2019 11:32:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ihcF7-0005zM-0F for 38645@debbugs.gnu.org; Wed, 18 Dec 2019 11:32:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ihcF1-0001yy-PJ; Wed, 18 Dec 2019 11:32:03 -0500 Original-Received: from [176.228.60.248] (port=1147 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ihcEy-00067i-LF; Wed, 18 Dec 2019 11:32:01 -0500 In-reply-to: <86r211sy6b.fsf@gmail.com> (ynyaaa@gmail.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:173523 Archived-At: > From: ynyaaa@gmail.com > Cc: bug-gnu-emacs@gnu.org, 38645@debbugs.gnu.org > Date: Wed, 18 Dec 2019 19:52:44 +0900 > > Evaluate the form below and type 3 2 1, minibuffer window shrinks each > time. This behavior is inconsistent with read-string. > To check echo area contents just before read-string, type 3 4 > and the tmp variable value is nil, which indicates that the echo area > has been cleared without shrinking the minibuffer window. > > (let ((buf (generate-new-buffer "tmp")) > (map (make-sparse-keymap))) > (switch-to-buffer buf) > (define-key map "1" (lambda () (interactive) (message "1"))) > (define-key map "2" (lambda () (interactive) (message "a\nb"))) > (define-key map "3" (lambda () (interactive) (message "A\nB\nC"))) > (define-key map "4" (lambda () (interactive) > (let ((tmp (current-message))) > (read-string "input: ") > (message "tmp: %s" tmp)))) > (use-local-map map)) > > > By the way, read-string with empty PROMPT make the minibuffer window > shrink. > > (progn > (message "1\n2") > (read-string "")) > > Also it make the window shrink when all the minibuffer content is > deleted, even though read-string is not finished. > > M-: (read-string "") RET > C-q C-j > C-q C-j > DEL > DEL I still fail to see the problem in these use cases. Is the problem that from your POV the behavior wrt shrinking the mini-window happens sometimes, but not always? If so, this is not a bug: by default Emacs does not try too hard to do so, although when a command finishes and Emacs runs a full redisplay cycle, it usually does shrink it. If you set resize-mini-windows to t, it tries harder, and will shrink in many cases even in the middle of a running command. Also please keep in mind that the mini-window shows not only the echo area, but also the minibuffer (when it's active), so the fact that the echo-area message has been cleared does not yet mean the mini-window can be shrunk -- if the minibuffer is active, it usually won't be. At this point please tell if you have real-life use cases where this behavior causes real problems, like concealing some part of the echo-area message, and if so, please describe those real-life use cases. If this is just about consistency, I tend not to touch this area of the display engine, as it is somewhat delicate and easy to break. Thanks.