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: Thu, 14 Nov 2019 08:28:50 -0800 (PST) Message-ID: 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> 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="243886"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Lars Ingebrigtsen , Juri Linkov , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 14 17:30:14 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 1iVI0b-0011Ja-N1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Nov 2019 17:30:13 +0100 Original-Received: from localhost ([::1]:59534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVI0a-0002Fq-Cd for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Nov 2019 11:30:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45835) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVI0S-0002FM-G9 for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2019 11:30:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVI0R-00086b-8j for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2019 11:30:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54498) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iVI0R-00086V-4i for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2019 11:30:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iVI0Q-0004ay-Rq for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2019 11:30: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: Thu, 14 Nov 2019 16:30:02 +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.157374894817558 (code B ref 17272); Thu, 14 Nov 2019 16:30:02 +0000 Original-Received: (at 17272) by debbugs.gnu.org; 14 Nov 2019 16:29:08 +0000 Original-Received: from localhost ([127.0.0.1]:35086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVHzY-0004Z2-14 for submit@debbugs.gnu.org; Thu, 14 Nov 2019 11:29:08 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:38440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVHzT-0004YL-Cs; Thu, 14 Nov 2019 11:29:05 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAEGSuLv187675; Thu, 14 Nov 2019 16:28:56 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=/EEDpq0DGTAYunnCae2/wHP1+wFmtKAn/hz2ZjD+Me4=; b=EqPYNZs3iKXKIoB1bwcXEwzTW7PlnKZY8K4DOpGhMWaf5Sy5nH02N3iH2LRNMVO8HsuX Q9rWYmswo+3n6m/DoPZLWYbHmXjZ8ebLZ/pEjPNUT2f3voolVlzc+Me9f54t5YKBoz0T mAe2icYGw2GOdISYccuAnGgI0DIKCz2+VwcQsQ0sWkOs56k892FVSMRoeeTrMkNmnWlp UwmKm5HJfS3J+KV8SHIp1CJGgwLTL4+CYA8HhRFKllbyZugjleAq5SFwkBiX+uofTES2 hy355ISKqXf78k2D2W7TtKqwKLCd81B0fHHg8KypcPG+1sxqDeVBcc3IPSLj+1Ur+obL lw== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2w5ndqmc2m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Nov 2019 16:28:55 +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 xAEGScH2031885; Thu, 14 Nov 2019 16:28:53 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2w8g19nde1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Nov 2019 16:28:53 +0000 Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAEGSp8D014784; Thu, 14 Nov 2019 16:28:51 GMT In-Reply-To: <87mucya2a7.fsf@web.de> 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=9440 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=884 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140149 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9440 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=953 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140149 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:171599 Archived-At: > > [I still don't understand why it's said that your > > minibuffer input gets permanently hidden, in that > > scenario. I suppose that if the result of your > > `y-or-n-p' answer causes Emacs to quit or to kill > > stuff then that could happen, but I wouldn't think > > it would happen generally. Your input is in the > > minibuffer; the prompt from `y-or-n-p' is in the > > echo area.] >=20 > You misunderstood the word "permanently": We didn't mean you can't get > the y-or-n-p prompt back but that the prompt doesn't come back from > alone without user interaction, no matter how long you wait. The statement made wasn't about the prompt. It was about minibuffer input. My reply was that input is in the minibuffer, and both `message' and `y-or-n-p' write to the echo area (or at least they both did), so I can't imagine how minibuffer input is lost or "permanently hidden". > > > AFAICT only the behavior for these special > > > situations have been made a bit more user > > > friendly, and all other calls of message or > > > mb-message are uneffected (is that correct, > > > Juri?) so that third party stuff should > > > not be affected. > > > > I see. I hope that's right. I got the impression > > that a change was being made to detect whether the > > minibuffer is active, and, when so, make `message' > > calls behave instead like `minibuffer-message'. > > That would not be good. > > > > Can someone please confirm that that's not the case? >=20 > I think Juri did that. I didn't think so - not explicitly. He confirmed your "AFAICT only the behavior..." description, but also your statement that "`y-or-n-p' has been reimplemented to use read-from-minibuffer instead of read-key" statement. (Or perhaps just one of those?) There are mentions in this thread (and others?) of `minibuffer-message' being used in place of `message' when the minibuffer is active. So it's still not clear to me that such a change is not being made. And I disagreed that `y-or-n-p' should read from the minibuffer instead of reading a key. I guessed that the problem that that tries to solve should still exist for all uses of `read-key' that issue a prompt (which is probably all uses of it). No? A general statement that "third party stuff should not be affected" is great, as far as it goes. But I guess I'll just have to wait till Emacs 27 to see the devil in the details.