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#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Date: Sat, 16 Nov 2019 17:42:06 -0800 (PST) Message-ID: <266012df-8baf-469d-83b0-25f9cfdff603@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> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <87v9rjv45e.fsf@web.de> 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="39068"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Lars Ingebrigtsen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org To: Michael Heerdegen , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 17 02:43:24 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 1iW9b2-000A2P-5d for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Nov 2019 02:43:24 +0100 Original-Received: from localhost ([::1]:51710 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iW9b0-0007dC-UT for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2019 20:43:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55237) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iW9aj-0007cx-3H for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2019 20:43:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iW9ah-0005oM-3N for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2019 20:43:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59342) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iW9ag-0005o2-KK for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2019 20:43:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iW9ag-0003mq-Hr for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2019 20:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2019 01:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19064 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 19064-submit@debbugs.gnu.org id=B19064.157395494014490 (code B ref 19064); Sun, 17 Nov 2019 01:43:02 +0000 Original-Received: (at 19064) by debbugs.gnu.org; 17 Nov 2019 01:42:20 +0000 Original-Received: from localhost ([127.0.0.1]:39927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW9Zz-0003ld-OK for submit@debbugs.gnu.org; Sat, 16 Nov 2019 20:42:20 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:53792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW9Zw-0003lM-Uo; Sat, 16 Nov 2019 20:42:17 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAH1dZDX081391; Sun, 17 Nov 2019 01:42:10 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=whZXLrGhQ3s2MbmlZbsvYWQNFR5IhHdO6m19EBqgbe8=; b=ciU/Lv8f9/h+kvnDdSIwWb6WxESBm26XszVviRhFc7WhEV5QIuRqbKFDKBQKd7SKQqRl QsWW127FQR9NR08tcS3nxSRT+AxGoLgTHBj2h0Bson4T/k+JKU187u/KQuYMEGAi7ufw jWqWE8SZuf1mKy1n46QCF0aj9WI6c48xo7UK+KKVaz4U6RQ3bZoCp3QSBhT3u/6r40C6 tpr3SWd+1njboZ4gwe575yOTTmlyy+FvWX1oT98ciSgzqw7koYQrA6wzAgiaQ8hGOnfK I2PSbGk3MEASjGaBN4NzLIW6QObjQ8IN3QSWkD6vlia7wPm6YXiZKkh9/iV4FMEg06Rs 9g== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2wa8htacer-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 Nov 2019 01:42:10 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAH1X7aJ108885; Sun, 17 Nov 2019 01:42:10 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2watjv4emd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 Nov 2019 01:42:10 +0000 Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAH1g7oc008775; Sun, 17 Nov 2019 01:42:07 GMT In-Reply-To: <87v9rjv45e.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9443 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-1911140001 definitions=main-1911170012 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9443 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-1911140001 definitions=main-1911170013 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:171748 Archived-At: > > >>> I think the posters just confused minibuffer > > >>> and echo area for the case of y-or-n-p then > > >>> (at least did I). > > >> > > >> That's easy to do. But the statement wasn't just > > >> about the minibuffer when echo area was meant, or > > >> vice versa. The claim was that _user input_ (not > > >> a prompt) became permanently hidden. > > > > > > I don't know if that was also a mistake or really > > > meant like that. > > > > This is not a mistake. So you're saying it wasn't a mistake for you to say that _user input_ (not a prompt) is permanently hidden? In that case, what's the scenario where user input is permanently hidden? My claim was that I don't see how it can happen that your input in the minibuffer becomes permanently hidden. Michael guessed that you maybe meant that a prompt, not user input, becomes hidden. But it seems that's not the case, so please provide a recipe for the permanent hiding of your input. > > Permanently hidden user input is a serious > > problem and security threat. I'd agree with that, of course - it can be. > > Today I started compilation, then in a Dired buffer > > requested files deletion that displayed the prompt: > > > > Delete D [54 files] (y or n) > > > > But before I had a chance to answer the prompt, > > compilation finished and obscured the prompt=20 See, now we're back to talking about the _prompt_, _not user input_ being obscured, right? The prompt is sent to the echo area. At least I think it is. I thought it was also logged in `*Messages*', but I don't see it there. Perhaps that happens only when the writing to the echo area uses an explicit call to `message'? In any case, I don't think it's in the minibuffer. If you have input in the minibuffer then it should still be there, after that prompting. I'm guessing that `y-or-n-p' is being used. That function calls `read-key', which calls `read-key-sequence-vector', a C function. Apparently the prompt doesn't get logged in `*Messages*' - I don't know why. > > with this message permanently: Compilation finished Yes, a subsequent message to the echo area can wipe out a message (in this case a prompt) that was there. I'd hope that both messages (the `y-or-n-p' prompt and the "Compilation finished" message) would be in `*Messages*', at least. Doesn't seem good, to me, that that doesn't seem to be the case. Not that it would be enough, to solve the problem described, just to log both messages in `*Messages*'. But at least that would mean that the prompt would not be permanently lost. It would anyway be lost from the echo area, however - yes. > > So I forgot about what was in the prompt :-( I agree that this is an unfortunate scenario. I don't want it to happen any more than you do. But what exactly is the recipe? How was it that you "requested files deletion that displayed the prompt" that you show? I'm using Emacs 26.3. `dired-do-flagged-delete' shows `Delete D [54 files] (yes or no)'. It sounds like you've maybe set `dired-deletion-confirmer' to `y-or-n-p'? (It's default value is `yes-or-no-p'.) If you had seen `(yes or no)' then you would be using the minibuffer. And if you had started to type, say, `ye' for `yes', then your minibuffer input would have been obscured only temporarily by the compilation message. And the prompt would not have been lost from the echo area by replacement by a subsequent message from the compilation process, because `yes-or-no-p' prompts in the minibuffer, not in the echo area. If you're using `y-or-n-p' then the problem has nothing at all to do with the minibuffer, AFAIK. Unlike `yes-or-no-p', which uses the minibuffer, `y-or-n-p' prompts using the echo area. And in that case the compilation message wipes out the `y-or-n-p' prompt. I would think that the first step toward a fix would be to make sure that the `y-or-n-p' prompt at least gets logged in `*Messages*'. (I thought it would be - I'm surprised.) But of course that doesn't solve the real problem. The problem, IIUC, is that messages to the echo area can wipe out earlier messages there. And `y-or-n-p', which uses the echo area for its "prompt", is (unfortunately, IMO) being used in your case for an important operation that destroys data (deletes files). The default is `yes-or-no-p' for `dired-deletion-confirmer' for a good reason. So what's the solution, for multiple writes to the echo area, including perhaps by async processes? Using the echo area for a "prompt" is, IMO, not a great idea. It's OK for some operations, but not for something delicate/critical. Users and code should not depend on a `y-or-n-p' interaction for something important. It's not just about writing a prompt to the echo area. The `y-or-n-p' - or any other `read-key' interaction, is hardly atomic, i.e., modal. `yes-or-no-p' and other minibuffer interactions aren't atomic either, but they really don't have the problem you raised. (And that's why I responded as I did. I thought you were talking about a use of the minibuffer and losing minibuffer input.) I made a suggestion in this thread, to present the `read-key' prompt, e.g. in the case where you use `y-or-n-p', not in the echo area (danger), but in a pop-up window: To read a key, the prompt basically _tells_ the the user to hit a key. It's not looking to read any input into a buffer - minibuffer or otherwise. Why not instead just put the prompt in a temporary (unselected) popup window or undecorated frame? And it's possible to use a modal dialog that keeps the prompt visible until you end/dismiss the dialog. One possibility is to add the prompt to the window that pops up to list the files to be deleted. IIUC, the general problem you present is this: 1. You are prompted in the echo area. 2. An async process writes a message to the echo area, wiping out the prompt from #1. That's to be avoided, first of all, IMO. That would be the first "fix" - don't do that. Maybe dialogs should never prompt in the echo area. Maybe they should instead open a window for the needed interaction, including the prompt. Maybe they should be modal in some cases. So what about use of the minibuffer as such a window for a dialog? For most uses it's fine. If it had been used in this case, e.g., if the default value of `dired-deletion-confirmer' (`yes-or-no-p') were used, then I don't think you would have had your problem. Yes, your minibuffer interaction would have been interrupted by the echo area, to show the compilation message. But the prompt and your partial input would have been restored after a brief delay, when the minibuffer was again shown in place of the echo area. I said "for most uses it's fine." That does not mean that the minibuffer is always the ideal way to realize a prompt-and-read-reply dialog. For something critical a modal dialog could be appropriate. What about the compilation-finished message? Maybe that shouldn't just plop down in the echo area. IOW, maybe there's some responsibility here for async operations that report status, to use another method - something that won't interfere with the echo area. There are no doubt other ways to try to deal with your problem. But I disagree with either of the following approaches. (It's still not clear to me whether you're trying to do either of these, but that's been my impression at some points of this discussion.) 1. Make `y-or-n-p' use the minibuffer. 2. Make `message' turn into `minibuffer-message' whenever the minibuffer is active. I've spoken to both of those. I don't want to bore you by repeating a lot, but if you want to talk more about those then I will. Summary about them (my opinion): 1. The minibuffer is generally not the place to read a single character or a key. It's a buffer for editing and entering multi-char input. `y-or-n-p' and other functions that use `read-key' and similar have good use cases, based on their advantages, i.e., on their specific behavior. They do not involve entering text and sending it by hitting RET. They're not associated with any particular window or buffer, with respect to the user input. The input action is to just hit a key. That's their advantage - and their disadvantage. And yes, they prompt in the echo area (AFAIK), which is not so great. We could consider letting them, alternatively, prompt somewhere else, such as in a popup. 2. During a minibuffer interaction (i.e., when the minibuffer is active) all kinds of things can go on. That includes recursive minibuffers, popping up and selecting other windows, using the echo area for temporal messages - anything at all, really. In particular, `message' can be useful when the minibuffer is active. So can `minibuffer-message'. Both are useful; neither replaces the other.=20 > > Since Drew doesn't want to improve safety > > to cover all such cases, Right; that's a fair thing to say, Juri. Drew doesn't want safety. Drew wants you to lose your data. Sheesh. Where do you get off saying such things? I spoke only to #1 and #2 above. Please do not make `y-or-n-p' read from the minibuffer, and please do not, when the minibuffer is active, force `message' to do what `minibuffer-message' does. I don't know if either is something you're trying to do, but both of those would be super misguided, IMO. And unnecessary. > > we need to address these issues one by one [...] >=20 > That's nearly impossible to do, and once you are done, > new cases will likely be introduced in the future. > Drew, how would you address this class of problems? See above. Hope it helps. I don't claim to have all the answers, and I might not understand the problem well. But I'm pretty sure that #1 and #2 above are not good. * Don't use `y-or-n-p' for something important. * Async operations should maybe not report simply by writing to the echo area, since: (1) it shares real estate with the minibuffer, and writing to it can interrupt a user interaction there; and=20 (2) it can overwrite other messages to the echo area (including from other async operations). * Maybe some important interactions should be modal, i.e., more or less blocking you from doing other things till the modal interaction is done; and maybe blocking reception of some async report messages. (They shouldn't block `C-g', though.) I'm not the one changing anything. If you leave the default value of `dired-deletion-confirmer' as `yes-or-no-p' then I don't think you'll have the problem you reported and are trying to fix. I'm not saying that there isn't a general potential problem, but I don't think it's where you said it is. I'm not the one changing anything. But those who are should maybe come up with suggestions - for general discussion. Why would this kind of thing be done in a bug thread (several bug threads?) but at the same time try to handle a general problem in a general way? Why wouldn't it instead be brought up at emacs-devel, where lots of informed people can speak to it? Emacs 27 isn't released yet. I have a recent snapshot now, but it doesn't show lots of things that have apparently been changed recently. It's frustrating to get a new Emacs release and find that lots of stuff that's always worked is broken because someone implemented what they thought was an improvement. Such things should generally be added as new, optional features, not just replace longstanding behavior. IMHO, the minibuffer ain't broke, and likewise `message' and the echo area. Can there be bad use cases, problems that we can identify? Sure. But let's not throw out the baby with the bath water. Before changing something like `y-or-n-p' or `message' (again, I'm not sure that's what you're doing - not clear to me), why not bring it up for general discussion?