From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New multi-command facility displays in the wrong echo area. Date: Mon, 12 Oct 2020 17:37:33 +0300 Message-ID: <837drv4ij6.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28150"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Gregory Heytings , Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 12 16:43:51 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 1kRz3G-0007Ea-QO for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 16:43:50 +0200 Original-Received: from localhost ([::1]:54840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRz3F-0001ch-RI for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 10:43:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38528) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRyx7-0003Qt-DH for emacs-devel@gnu.org; Mon, 12 Oct 2020 10:37:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43976) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRyx6-0007ay-Kp; Mon, 12 Oct 2020 10:37:28 -0400 Original-Received: from [176.228.60.248] (port=1046 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kRyx5-0003gJ-Vm; Mon, 12 Oct 2020 10:37:28 -0400 In-Reply-To: (message from Gregory Heytings on Mon, 12 Oct 2020 09:12:05 +0000) 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:257467 Archived-At: > Date: Mon, 12 Oct 2020 09:12:05 +0000 > From: Gregory Heytings > cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > 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. Right. > 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)) So you suggest in that case to overwrite the minibuffer prompt, like Emacs 26 did? I'm not sure I like this: it would bring back many problems this feature was supposed to fix. Can we do better than obliterating the entire minibuffer text? Juri, any ideas? In any case, I think the condition could be relaxed: we only care about how much space is left from the minibuffer text's end till the end of the screen line, so "if minibuffer text size modulo window-width is less than something" would be better, I think. E.g., if you use 70 instead of 67 in your recipe, the problem is mostly gone. Also, it would be safer to use string-width instead of the number of characters, or even window-text-pixel-size: some people do customize the faces used in the minibuffer. > 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? This has some history. You are welcome to read the discussion in bug#38457, especially starting at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38457#17 You will see that many issues were discussed, the dangers were expected, and as result the change became less invasive, which was especially important because the release cycle was about to start. However, it didn't sound wise to reject the changes outright because they've fixed several important use cases that were an annoyance for a long time. But yes, any significant change in such basic functionality runs a risk to break something, especially in relatively rare use cases (max-mini-window-height set to 1, followed by "C-x o" out of the minibuffer). This risk is inherent part of development, and sometimes mistakes are being made. We try at least not to make the mistakes we know about. > 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. Maybe because we are now wiser and don't want to repeat past mistakes? Btw, the C-s use case is special, you can see that if you do just this: C-x C-f C-s Juri, would it make sense to do something special for Isearch in the "C-x o" case as well? Or am I wrong, and there's nothing special with Isearch using the mini-window here?