From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: New multi-command facility displays in the wrong echo area. Date: Mon, 12 Oct 2020 12:00:14 +0000 Message-ID: <20201012120014.GA22249@ACM> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32565"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 12 14:03:59 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 1kRwYY-0008Kn-Lh for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 14:03:58 +0200 Original-Received: from localhost ([::1]:55500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRwYX-0004Xk-Mn for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 08:03:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRwV7-0001Il-47 for emacs-devel@gnu.org; Mon, 12 Oct 2020 08:00:25 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:25848 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kRwV3-0001td-9M for emacs-devel@gnu.org; Mon, 12 Oct 2020 08:00:24 -0400 Original-Received: (qmail 80090 invoked by uid 3782); 12 Oct 2020 12:00:15 -0000 Original-Received: from acm.muc.de (p4fe15c8d.dip0.t-ipconnect.de [79.225.92.141]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Mon, 12 Oct 2020 14:00:14 +0200 Original-Received: (qmail 22320 invoked by uid 1000); 12 Oct 2020 12:00:14 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/12 08:00:16 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] 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_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:257460 Archived-At: Hello, Gregory. On Mon, Oct 12, 2020 at 09:12:05 +0000, Gregory Heytings wrote: > > 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. > 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. Perhaps there's a less heuristic way of dealing with it. I haven't looked into it closely. > 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! > 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. Emacs is ~45 years old. Some of the maintainers have been on the job for more than half of that time. They've developed a feel for what fits in harmoniously and what could easily jar and cause problems in the future. Given the complexity of Emacs, we can't really afford to wait until potential problems become real problems - there might just be too many of these to cope with. For what it's worth, others (including me) have had effective bug fixes rejected on various grounds. For better or for worse, it's just part of Emacs development. -- Alan Mackenzie (Nuremberg, Germany).