From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Date: Tue, 12 Nov 2019 15:34:45 +0000 (UTC) Message-ID: <53c55db5-d623-4946-af2e-d141e7bc7acd@default> References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="249710"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org To: Lars Ingebrigtsen , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 12 16:36:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iUYDE-0012nU-Uh for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2019 16:36:13 +0100 Original-Received: from localhost ([::1]:36816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUYDD-00015v-7r for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2019 10:36:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46109) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUYD5-00015a-R5 for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 10:36:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iUYD4-0002TV-5m for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 10:36:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49381) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iUYD4-0002TE-0W for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 10:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iUYD3-0002TW-PN for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 10:36:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2019 15:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15735729039430 (code B ref 17272); Tue, 12 Nov 2019 15:36:01 +0000 Original-Received: (at 17272) by debbugs.gnu.org; 12 Nov 2019 15:35:03 +0000 Original-Received: from localhost ([127.0.0.1]:58201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUYC6-0002Rw-Q2 for submit@debbugs.gnu.org; Tue, 12 Nov 2019 10:35:03 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:58872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUYC3-0002RK-69; Tue, 12 Nov 2019 10:35:00 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xACFOjlB071273; Tue, 12 Nov 2019 15:34:52 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-2019-08-05; bh=oS0/8YUg+GFHF0Eh5Tg+zT1y2R4DS77yi7w7Iti6Jsw=; b=TSlD+Adr+bJSwRact68V/8pjsi/4qgN+TtbrpJ0vZAe4qSpCeNlnc7AAvUeDZ2MmeUni B46d04VLSn5Eb0jTEyFjl/YpBQZ3O8qqFY3GZSJq/uzLNsMF6SAoxK8o7fWqK/3VXLfV DmjuqeQ9e85Eyd1yUu6tz5WJNLcXuc+fuxB4LelJRD/vR5IXkSiMO/Q6en5mvmUPDl61 s1/20tcuJ7R17FZwG2UXKa1vJj+VBGgM/WZ+DLGVjlWaJnviwDkgAzxwlGcIHsEtVAzM UA+BFo1mGx44c6owzwOvUHMzgEdfPSwZ5Hk5ydRekuIWu0vwnd5JCyvmRK2ank84doM7 Qg== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2w5p3qnhef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Nov 2019 15:34:52 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xACFOTE4102396; Tue, 12 Nov 2019 15:34:51 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2w7vpmfjb9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Nov 2019 15:34:51 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xACFYkso032146; Tue, 12 Nov 2019 15:34:49 GMT In-Reply-To: <87d0dxyh7z.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9438 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911120134 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9438 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911120134 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:171458 Archived-At: > > But a question: after reversing the dependency should it be > > customizable to get back an old behavior for Drew? >=20 > I didn't quite understand what Drew wanted (to have the prompt be > overwritten?), but if so, a user option would be trivial to add, > wouldn't it? Like `display-messages-in-minibuffer' or something? I'm sorry, but I can't follow this. I don't know what's been changed, or why. (There are even two bugs that are being handled here, apparently.) What I've said is that I object to an automatic attempt to determine, when the minibuffer is active, whether to realize the effect of `message' or the effect of `minibuffer-message'. The minibuffer can be active - or not - during any number of other activities. The minibuffer is for user input, but that space is also (as the echo area) for `message' output. And such output - messages to the user - can, and should be able to, be delivered while a user is using the minibuffer for input. Nothing wrong with that, in general. `message' is often, and can always be, associated with an _interruption_: `sit-for' or `sleep-for'. This is part of a normal UI dialog/interaction - one kind of such interaction. This applies also when you're using the minibuffer. It can make sense to interrupt inputting briefly, to deliver a message. `message', unlike `minibuffer-message', not only interrupts input (switching to the echo area). By doing so it also takes over that complete space. Yes, that hides your input temporarily - but that's the point. The complete space is available for a message. It's saying, "Forget about your inputting for a moment, and read this important announcement." (`message' also logs messages, which can be very important.) `minibuffer-message' is limited to appending to your minibuffer input. Much less space available. And no interruption, no real separation from your input (apart from the brackets). Minibuffer input can be long and complex, even using multiple lines. `message' allows complete separation of the input space from the output space. But yes, it separates in time, not space. Is that bad? good? It depends. Consider also recursive minibuffers. Imagine, in fact, that the minibuffer is _always_ active. You can continue to use Emacs normally in this scenario. `message' needs to work normally, as does `minibuffer-message', regardless of whether the minibuffer is active. In sum, BOTH `message' and `minibuffer-message' have their uses when the minibuffer is active. They are _different_. Neither is good or bad. It is absolutely wrong - misguided - to suppose that when the minibuffer is active all messages should be delivered using `minibuffer-message'. It's up to the functions that _use_ these two output functions to DTRT. Consider an asynchronous process trying to deliver progress or result messages. Should it use the echo area? If so, maybe `message' with a hard interruption (`sleep-for') is appropriate. Or maybe it's appropriate to pop up a buffer to show the messages. Or maybe it's appropriate to use `message' if the minibuffer is active or `minibuffer-message' if not. It all depends. There are lots of UI and reporting possibilities. It's up to the functions that are trying to tell the user something to decide and do what's appropriate. It's not up to the minibuffer ("Am I active?") to decide. No simple rule/condition (e.g. minibuffer is active) can reasonably determine which output effect should be used in a particular situation. This BUG is about a particular scenario where the functions that use output functions interact badly during minibuffer input. That's a PARTICULAR scenario. A proper fix for the bug is to find a solution specific to that scenario - to coordinate or otherwise referee among the participants that vie for the user's attention. Not taking account of the particular scenario is wrong (and perhaps a cop-out). Determine the real, problematic scenario, and provide a remedy for that. Don't try to elevate this to some general, abstract, blanket, one-size-fits-all, hard-coded rule to finesse messages during minibuffer input. Analyze the real, specific problem in the reported scenario, and provide a solution for that. Don't overreach. Don't paint everything the same color just because there's a scenario where the color scheme is problematic. That's my point. Please do _not_ impose `minibuffer-message' as a replacement for `message' when the minibuffer is active. Don't stop _callers_ from determining the appropriate behavior. If a caller uses `message' then respect that. If the caller does something stupid then fix the caller. I said (perhaps in this thread) that I have a function, `icicle-msg-maybe-in-minibuffer', that does this - something similar to what I guess you have in mind imposing in some systematic way: (icicle-msg-maybe-in-minibuffer FORMAT-STRING &rest ARGS) Display FORMAT-STRING as a message. If called with the minibuffer inactive, use 'message'. Otherwise: If 'icicle-minibuffer-message-ok-p', then use 'minibuffer-message'. Else do nothing (no message display). But the point is that that's just another output function, available for use by callers. I don't just impose that systematically. For some callers, using that instead of `message', or instead of `minibuffer-message', makes sense. For others it makes sense to just use `message' or `minibuffer-message'. (And you'll notice that I even provide a global variable, `icicle-minibuffer-message-ok-p', that can be bound to override substituting `minibuffer-message' for `message'.) I don't object to ever using `minibuffer-message' in place of `message'. I object to doing that systematically. I object to doing that behind the backs of callers - let the callers decide. Can odd or unpleasant behavior sometimes result, due to caller behavior conflicts? Of course. That's rare, IME, but it can happen. When it does. it needs to be fixed - for that particular scenario. And in particular, if there's something very important that a caller is doing - some very important message communication, then probably something other than `message' and other than `minibuffer-message' is appropriate - e.g., a popup, maybe even a modal, dialog. Dunno whether this long reply makes clear "what Drew wanted". I hope it helps. And I hope you'll reconsider the simplistic "solution" that I think you've planned. If I'm mistaken wrt the planned solution, apologies. At least I hope I've made clear my objection to what I've thought the plan is. Thanks for listening.