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 09:12:05 +0000 Message-ID: References: <20201009163445.GB4027@ACM> <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> 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="21691"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 12 11:13:11 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 1kRttH-0005Pj-Dr for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 11:13:11 +0200 Original-Received: from localhost ([::1]:39556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRttG-00040A-GU for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 05:13:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRtsP-0003Fm-Mm for emacs-devel@gnu.org; Mon, 12 Oct 2020 05:12:17 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:57695) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRtsN-0004xu-HQ; Mon, 12 Oct 2020 05:12:17 -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 09C9C9vK013937 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 12 Oct 2020 09:12:09 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 09C9CVeZ026798; Mon, 12 Oct 2020 09:12:31 GMT In-Reply-To: <83imbg4yl3.fsf@gnu.org> 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 04:05:08 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:257456 Archived-At: > > 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. I suggest the following fourth condition in set-minibuffer-message: (< (buffer-size (window-buffer (active-minibuffer-window))) (/ (frame-width (window-frame (active-minibuffer-window))) 2)) Of course it's a heuristic (it could still fail when the face used in the miniwindow is different, and larger than, the default face), but it should catch 99.99% of the remaining error cases. 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? It is even more amazing that, at the same time, my proposed solution to display completion candidates in the minibuffer is rejected on the grounds that it could cause "potential problems", when so far no one has managed to show a case in which it would create an actual problem.