From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: New multi-command facility displays in the wrong echo area. Date: Mon, 12 Oct 2020 12:18:24 +0000 Message-ID: References: <20201009203810.GC4027@ACM> <83imbi609a.fsf@gnu.org> <20201010103233.GB5662@ACM> <834kn25o6b.fsf@gnu.org> <20201010124446.GC5662@ACM> <831ri65jpc.fsf@gnu.org> <83zh4u44mx.fsf@gnu.org> <83imbg4yl3.fsf@gnu.org> <20201012120014.GA22249@ACM> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37779"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 12 14:23:03 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kRwr1-0009ka-0j for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 14:23:03 +0200 Original-Received: from localhost ([::1]:60300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRwqz-0002M5-Pq for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 08:23:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRwmk-00066O-5t for emacs-devel@gnu.org; Mon, 12 Oct 2020 08:18:38 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:57253) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRwmf-0004oH-RD; Mon, 12 Oct 2020 08:18:37 -0400 Original-Received: from sdf.org (IDENT:ghe@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 09CCIRqB015893 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 12 Oct 2020 12:18:27 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 09CCIQfg009841; Mon, 12 Oct 2020 12:18:26 GMT In-Reply-To: <20201012120014.GA22249@ACM> Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/12 08:18:30 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257461 Archived-At: Hi Alan, >>> Thanks. So I think your change is a definite improvement, and I >>> therefore installed it on the emacs-27 branch. >> >> Thank you. Alas, it's not the only bug of this new feature. A recipe: >> >> emacs -Q >> (progn >> (set-frame-width nil 80) >> (setq max-mini-window-height 1) >> (setq default-directory (concat "/" (make-string 67 ?a))) >> (call-interactively 'find-file)) >> press C-x o >> press C-s >> >> At this point you see no indication that I-search has been started. >> (If you look close enough, the only thing you can see is a curly arrow >> in the right fringe of the miniwindow.) Likewise, if you press C-x >> C-s, you see no indication that changes have been saved (or not). And >> so forth. > > Well, whoever sees/doesn't see this did set max-mini-window-height to 1. > Surely this is a case of you ask for it, you get it. > With earlier Emacsen that setting would not have had such effect, the contents of the minibuffer would have been overwritten by the echo area in all cases. Setting max-mini-window-height to 1 is perfectly valid, and by the way the same thing could happen with max-mini-window-height set to 2 and a longer input, and so forth. This also could happen for those who use independent miniwindows, which have a fixed size. >> It is amazing that such a feature got accepted, was included in an >> official Emacs release, and became Emacs' default behavior, without >> even trying the two obvious cases to test: what happens when there is >> not enough free space in the minibuffer? and what happens when the >> active minibuffer is not on the same frame? > > Bugs are always obvious after somebody's pointed them out. Well done > for finding them! > I don't think so, these two cases are obvious things to check. I did not know about that feature before you sent your message three days ago, and after fixing the bug you found this bug is the second thing that immediately came to my mind.