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 15:41:35 +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> <837drv4ij6.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="1595"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Juri Linkov , 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 18:13:41 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 1kS0SD-0000JW-5W for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 18:13:41 +0200 Original-Received: from localhost ([::1]:44282 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS0SC-0001oh-5D for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 12:13:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRzxQ-0007dr-4V for emacs-devel@gnu.org; Mon, 12 Oct 2020 11:41:52 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:51878) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRzxJ-0008JO-Eu; Mon, 12 Oct 2020 11:41:51 -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 09CFfc1V007495 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 12 Oct 2020 15:41:38 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 09CFfxBK027399; Mon, 12 Oct 2020 15:41:59 GMT In-Reply-To: <837drv4ij6.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 11:41:42 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:257472 Archived-At: >> 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? > Yes, indeed. That's clearly better than not showing anything at all. When there is not enough space on the right of the current minibuffer contents, IMO it should be overwritten. > > I'm not sure I like this: it would bring back many problems this feature > was supposed to fix. > So far I did not know what problems that feature was supposed to fix, so I could not make a judgment on this. The NEWS item does not indicate what these problems were, and I had myself never encountered a situation where overwriting the current minibuffer contents was problematic. It seemed to me so far that it was only something more aesthetically pleasing. Now that I've read bug#38457, I see that this is not the case, but I'm not at all convinced by the proposed solution. Something like what eldoc does when the minibuffer is active (temporarily displaying the info at the beginning of the mode-line) would have been a much better and more robust solution. Otherwise, another solution would be to temporarily add a "zeroth" (or "minusoneth") line to the minibuffer with the message. > > 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. > The condition could be refined indeed, but the modulo operation you propose would not work with variable pitch faces. I intentionally proposed something simple, which should work in (almost) all cases. I'm an adept of the KISS principle. > > 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. > I won't comment on this. As I already said elsewhere, it's IMO awful to expect any code to do something like this. >> 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. > See above. I've now read that bug thread, and I'm not at all convinced that the chosen solution was TRT, quite the contrary. > > 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). > As I said to Alan, this recipe is just a recipe, it exhibits a more general problem. The same problem would happen with max-mini-window-height set to 2 and a longer text, with a miniwindow only frame, with a small enough Emacs frame, and so forth. > > 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. > Well... no: the bug#38457 thread contains a message (#317) by Dmitry Gutov which points to a problem that is similar to the one I "discovered". BTW, he also suggests to use eldoc-minibuffer-message instead of the current solution. >> 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? > It seems to me that being wiser would mean taking the time to evaluate a proposed solution, instead of rejecting it outright based on a gut feeling.