From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: New multi-command facility displays in the wrong echo area. Date: Mon, 12 Oct 2020 10:12:39 -0700 (PDT) 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16093"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii , Gregory Heytings , Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 12 19:18:46 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 1kS1TB-00043x-LO for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 19:18:45 +0200 Original-Received: from localhost ([::1]:57106 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS1TA-0004Az-Mm for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 13:18:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51968) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS1PR-0001cl-VJ for emacs-devel@gnu.org; Mon, 12 Oct 2020 13:14:55 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:39360) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS1PP-0003Jl-Ga; Mon, 12 Oct 2020 13:14:53 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09CHDiY4046946; Mon, 12 Oct 2020 17:14:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=IznuhN89dxQCwWo2dBZBzqrfBCh7vho2lzlRruohmYM=; b=bsTZu+diOmcBa1+M4nF4jDuvtby3FOo45iK/plDd4sMweBauWLQsh3+SKvH+21PvyM4l KSJ3w5K9yYke1Fg4Ka6YE7i11XXPF7zo8X96r3GtdGJ49n4W+FpjMpteXZJH3MQL9BTJ a5YhtfmWP6KY+hJqMVQ5690CBjwGK32EKIch3DFBSrq6j18vMA9GhoWSaanqAysa4WX3 vsXoSkd+uGBLFKQqm9JuygctRKUNPw/Djfkhrz3oM98nMCeW9tsLudtF5dhAtucK9ApH Zjs4K2Lhu0iT5Ae1o3mH8Kl1oV8OnqUhOg9Jaw9O8kgjUFUYGFpQ98CMqRkOjoqZnPGp xQ== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 343vae4kne-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Oct 2020 17:14:48 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09CH4TRg064146; Mon, 12 Oct 2020 17:12:48 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 343pvv6ppq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Oct 2020 17:12:48 +0000 Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 09CHCewg008271; Mon, 12 Oct 2020 17:12:40 GMT In-Reply-To: <837drv4ij6.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5056.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9772 signatures=668681 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010120131 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9772 signatures=668681 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 clxscore=1015 impostorscore=0 phishscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010120132 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/12 12:22:48 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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:257485 Archived-At: > So you suggest in that case to overwrite the minibuffer > prompt, like Emacs 26 did? I do. > 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? Here's the problem, IMO: The minibuffer and echo area share the same space. For simple interactions with a user, there's no problem: either input and output are ordered in an expected way - no surprises. For complex interactions, which can include delayed echoes or echoes from other processes etc., `message' overwriting minibuffer input (and prompt) can be disconcerting, and it can even mean that a user might miss seeing a prompt, and thus become confused by the ensuing dialog. And as a result, a user could even end up mistakenly deleting data or worse. But complex interactions also allow the use of a minibuffer as almost a regular buffer - but one that also gives you access to sets of completions etc. They let you interrupt your current minibuffer "dialog" to do something else - examine something relevant in another buffer, make some changes to something - whatever. This is an important _feature_, not a bug. Minibuffer interaction is extremely flexible, precisely because it's more or less a normal buffer in more or less a normal window. The changes made for Emacs 27, AFAICT, break this. They prevent `message' from using the echo area whenever the minibuffer is active. In effect, they turn `message' into `minibuffer-message' when the minibuffer is active. There was a reason why we had both `message' and `minibuffer-message'. They're both useful when the minibuffer is active. Yes. And the usefulness of `message' in this context is precisely the same as the problem that you've sought to cure: by using the echo area it _interrupts_ the minibuffer dialog temporarily. And yes, that can mean hiding input and prompt. If you really feel that the problem you sought to fix is so serious, a proper fix would do this: in some way, _physically separate_ the minibuffer and the echo area, so they are _both_ visible at the same time. Problems solved; end of story. (But that needs to be designed and implemented well.) I object strongly to the "fix" that was made. And I don't think it should have been made with discussion only in a bug thread, not here. And I said so at the time. Nothing in that thread really addressed the real problem, IMO: echo area and minibuffer sharing the same space. That elephant in the room was ignored. Instead, the "fix" doubled down on that problem, in effect removing the rich possibilities of interaction (see complex interactions, above), and imposing ONLY the simple interaction: initiate minibuffer and prevent any use of the echo area until the minibuffer is exited. Same thing, BTW, with the change of `y-or-n-p' to using the minibuffer. That obviates using it during minibuffer input to just read a character (without using a recursive minibuffer etc.). These are, IMO, misguided "fixes" based on a too simple understanding of the minibuffer. Users used to be free, while the minibuffer was active, to do all sorts of things anywhere in Emacs. Now you've gone down the road of confining the minibuffer to a simple, linear, modal (in effect) ask-and-read behavior. That's not emacsy, IMO, and it breaks lots of my uses of the minibuffer. If `message' and the echo area are _sometimes_ a problem for _some_ minibuffer interactions then find a proper solution by, in some way, separating the echo area and minibuffer - NOT in time, and not modally, but in space. > 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. There should be no fiddling with minibuffer size, no guesses or dependencies on particular line length, etc. `minibuffer-message', appending text to the minibuffer input is definitely not something that should be overworked. It's for simple echoes of info directly relevant to the particular minibuffer interactions in progress. > > It is amazing that such a feature got accepted, was included in an offi= cial > Emacs release, and became Emacs' default behavior, without even trying th= e > two obvious cases to test: what happens when there is not enough free spa= ce > in the minibuffer? and what happens when the active minibuffer is not on = the > same frame? >=20 > This has some history. You are welcome to read the discussion in > bug#38457, especially starting at >=20 > https://urldefense.com/v3/__https://debbugs.gnu.org/cgi/bugreport.cgi?bug= =3D384 > 57*17__;Iw!!GqivPVa7Brio!KMf2iSSkE7JvnGnijw3sBBDFxR7wBlsojqiXwTMqPArBC1Nm= - > LDnhZG-lghgzrvY$ >=20 > 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. I don't agree that they've fixed several important use cases. Anything they've "fixed" has been with us from Day One - and has long been recognized as somewhat problematic. There was no urgency to toss this "fix" onto Emacs. > 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. I pointed to mistakes being made in that bug thread. That was ignored. There was entirely too much haste to "fix" the problems reported - which were nothing new. > > It is even more amazing that, at the same time, my proposed solution to > display completion candidates in the minibuffer is rejected on the ground= s > 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. >=20 > Maybe because we are now wiser and don't want to repeat past mistakes? >=20 > Btw, the C-s use case is special, you can see that if you do just > this: C-x C-f C-s I don't see anything special about that. Without changing to another buffer, `C-s' just searches your minibuffer input. It should do exactly that. And with changing to another buffer/window, `C-s' should just search that space instead. Nothing special here. Same behavior as a non-minibuffer buffer. The minibuffer is a general text-editing buffer, in addition to being a question-answering text-input area.