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#38457: 27.0.50; dabbrev-expand regression due to message change Date: Tue, 10 Dec 2019 09:51:59 -0800 (PST) Message-ID: <22c4d2d5-be81-471e-a521-4756d08f0c16@default> References: <8736e3vve8.fsf@gmx.net> <8736e2coyv.fsf@mail.linkov.net> <83y2vujd0y.fsf@gnu.org> <87blspm0sm.fsf@mail.linkov.net> <837e3ckbem.fsf@gnu.org> <871rtjn0kt.fsf@mail.linkov.net> <83lfrrigj8.fsf@gnu.org> <87eexiqps5.fsf@mail.linkov.net> <83lfrphp94.fsf@gnu.org> <87wob7g2jk.fsf@mail.linkov.net> <83k177ebs0.fsf@gnu.org> <87muc27prn.fsf@mail.linkov.net> <83tv6acgq5.fsf@gnu.org> <87eexdoygh.fsf@mail.linkov.net> <83tv68c0nb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="158001"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net To: HaiJun Zhang , Juri Linkov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 10 18:55:16 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 1iejjA-000exc-B4 for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 18:55:16 +0100 Original-Received: from localhost ([::1]:60612 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iejj8-0007Wr-Hr for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 12:55:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50434) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iejiy-0007WQ-DM for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:55:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iejiw-0007ko-Fl for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:55:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50594) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iejiw-0007kg-CI for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iejiw-0002Pk-B3 for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:55: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: Tue, 10 Dec 2019 17:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38457 X-GNU-PR-Package: emacs Original-Received: via spool by 38457-submit@debbugs.gnu.org id=B38457.15760004519191 (code B ref 38457); Tue, 10 Dec 2019 17:55:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 10 Dec 2019 17:54:11 +0000 Original-Received: from localhost ([127.0.0.1]:56561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieji6-0002O6-Dl for submit@debbugs.gnu.org; Tue, 10 Dec 2019 12:54:10 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:48920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieji4-0002Nr-NM for 38457@debbugs.gnu.org; Tue, 10 Dec 2019 12:54:09 -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 xBAHs0gO107912; Tue, 10 Dec 2019 17:54:03 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=hL5gSeDugyOzMZXbzoPVftPicHbB4y3yOEree0JDo1A=; b=D4CavB+2Sx3DEz7j1nwNe5t6zQODJP64u867GWylWOCfIoJ6l59AoynIox51lYsdFZ8y b6J6kuDb8IPwCp7T7Dgk5yWORlqwPRYLTJRBnHMzDVriDxNVEMAxhtpYWCx89hLGYXQi 5W07r/CK7C+Q+0qav0pUmV+RpuSRjVJjBixgrHtVXHK1xvorXQMEEY6e5vjNykqU8Ohg yzP8jhpamOF5nXDeVf0ZPifCsC/62XA3MCLoC3QhhdAF7O6wJcu9pZpyn50QFKvU8AaC AVab88K8xM/1dhgHmqYyktC6JVZx2KgdlpGDgVVkvZv9L9qS8CeRlwBVbtey+6kkD36H Tg== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2wr41q7ukp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Dec 2019 17:54:02 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xBAHmef0024036; Tue, 10 Dec 2019 17:52:02 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 2wte9admcv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Dec 2019 17:52:01 +0000 Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xBAHq0Vv020197; Tue, 10 Dec 2019 17:52:00 GMT In-Reply-To: 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=9467 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-1912100151 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9467 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=1011 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-1912100152 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:173149 Archived-At: > This is not a big problem. But minibuffer is a > basic UI of emacs. If it always has these bugs,=20 > users may think that minibuffer is not a good=20 > design. The minibuffer does _not_ "have these bugs". The problem is not the minibuffer. The problems are (1) asynchronous reporting that simply fires off a `message' blindly and (2) read-key interaction misused for important, essentially modal dialog, which, if during a minibuffer interaction, can be problematic. Emacs should provide other, safer ways to report status or impose a separate, modal dialog - ways that don't interfere with the minibuffer or the echo area. `message-box' and similar might be a start. But the behavior should be loggable, and it should be manipulable by program in various ways (prompting, whether modal, etc.), and it should be customizable by users. And developers should then be encouraged to change any existing code that provides async reporting or intermediate `y-or-n-p'-style dialogs to use the new constructs. At least those who use such things should be made aware that if they interrupt ongoing interactions then they can cause trouble. ___ And for the record, I disagree with simply automatically converting `message' behavior to `minibuffer-message' behavior in any systematic way. And I disagree with replacing `read-key' behavior for code like `y-or-n-p' with some read-from-the-minibuffer behavior in any systematic way. Some given uses of these things might be misguided and could be switched to using `minibuffer-message' - i.e., case by case. I'm not against `minibuffer-message' - it has its uses. But its uses mainly involve providing feedback about the ongoing minibuffer interaction - not reporting an outside event. One of the demonstrations of the "dangerous problem" was from Juri changing the value of variable `dired-deletion-confirmer' (which is _not_ a user option) from `yes-or-no-p' to `y-or-n-p', and then pointing to a resulting possible loss of user data. Well, duh - don't do that. That variable is there presumably for possible use by code in a context where the deletion dialog is sure, and controlled in some way. Many users seem to have chosen to just replace `yes-or-no-p' with `y-or-n-p, e.g. by aliasing. I think this is a practice that should be discouraged, or at least shouldn't be encouraged. Code that uses `yes-or-no-p' should be able to depend on its response not getting lost. Blindly substituting `y-or-n-p' is a bad idea, IMO. Like the problem of async reporting, reading a key/char can be problematic. Emacs can hopefully come up with additional ways, better in some contexts, to prompt for a key that reduce or eliminate the problem. But foregoing quick key/char reading by forcing use of the minibuffer is a bad "fix". Yes, there is a _real_ problem to be solved. There may even be more than one problem. (Async reporting is not the same as reading a key/char. The fixes are not necessarily the same.) But no, the one-size-fits-all approach taken so far is not a good solution, IMO. It screws the minibuffer - an editable buffer allowing complex user interactions. It screws with the difference, when using the minibuffer, between (1) the behavior of `message' (use the echo area, temporal interruption dismissable by typing) and (2) that of `minibuffer-message' (append output to the minibuffer input, no interruption - interfere spatially, not temporally). Each of those, minibuffer-message' and `message', has its particular uses and behavior while the minibuffer is active. And the various key/char-reading functions also have their particular uses. None of these should be tossed or stifled. Throwing all that to the wind, neutering it with a one-size-fits-all behavior, is a step backward. We should fix the various problems carefully - very carefully, and in context. Don't start with the supposition that the minibuffer is the problem. It's code that interferes with a minibuffer interaction that's the problem. Whether, when, and how to interrupt an existing dialog is the question. The answer is, "it depends". Emacs should be able to let a minibuffer interaction coexist safely with async reporting or key/char reading - without just stuffing in timeouts and tossing everything into `minibuffer-message'. In some cases an interaction (user dialog) may need to be _modal_ - finish reading a confirmation before allowing other action. This is about such an interaction coming about while another, minibuffer, dialog already exists. In other cases that's not necessary. The calling code that prompts for what should be a modal interaction should DTRT. It's not up to another, minibuffer, interaction to protect against such disruption. ___ Just one opinion - expressed in more detail in this and some other bug threads. The fact that this "fix" is spread over several bug threads, dealing with different=20 problematic behaviors, is perhaps a sign that this approach is not TRT. And such a far-reaching change should, I think, have been discussed in emacs-devel. Instead, in these bug threads we've been told that this is only a minor, localized change that will not affect 3rd-party code. That does _not_ seem to be the case, and I don't see how it could be.