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:53:22 -0800 (PST) Message-ID: <543d065c-9ee7-44bf-9fa5-99b7449c3498@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>> <<83h828b0lz.fsf@gnu.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="158115"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org To: Eli Zaretskii , juri@linkov.net, Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 10 18:55:17 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 1iejjB-000ezM-HY for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 18:55:17 +0100 Original-Received: from localhost ([::1]:60620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iejj9-0007YD-Qi for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 12:55:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50438) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iejiy-0007WR-Ku 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-0007lE-UB for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:55:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50595) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iejiw-0007l5-PA 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-0002Ps-Om 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.15760004539203 (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:13 +0000 Original-Received: from localhost ([127.0.0.1]:56563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieji8-0002OK-Vb for submit@debbugs.gnu.org; Tue, 10 Dec 2019 12:54:13 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:48976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieji6-0002Nu-8G for 38457@debbugs.gnu.org; Tue, 10 Dec 2019 12:54:10 -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 xBAHs3QJ107997; 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=rw+5s7aVwQEW2PLbJUZkVITbO6CHLRpet0re0FKAoOI=; b=nyBF5wS0GCE8eGihPjO2S9dlM/WT1Z1Be9XlJ0QofB55N4QYMwiFehjnMle5RHbCWV1/ JaGrG07kIn03zQgvs1k7TgjsagRlR9LdNGbKge6UirXpb4AI9Yc0hdOfMzLS4hla992a M8rCcAG4p97syzJntwy4AVqYwZK2RA0lxkn0AuChIC4aBrgI068QF8czY24ie7JJBRN8 QvhcVm2myJS8mv1SSVztBKkbR2NUuepmwtwkXbf57yZETvL0TJl1k2wjKp6EwaPQ1RRB ecWFReeZdny0sPtMSpScevLX9n2Bfmz2+RTvpgJXMNBF9Hn0Bt4zF1AGnGUviuDTvBm8 UQ== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2wr41q7um0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Dec 2019 17:54:03 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xBAHs0mH045168; Tue, 10 Dec 2019 17:54:03 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2wt6bcwkhs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Dec 2019 17:54:00 +0000 Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xBAHrN9r014965; Tue, 10 Dec 2019 17:53:23 GMT In-Reply-To: <<83h828b0lz.fsf@gnu.org>> 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-1912100152 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=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-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:173150 Archived-At: > Actually, the more I think about this the less I like the idea of > calling minibuffer-message instead of 'message' under some > circumstances, any circumstances. minibuffer-message is meant for > very different use case: temporarily displaying a message for a short > time. The messages it displays are usually ephemeral and dispensable; > if the user misses such a message, no big deal. >=20 > By contrast, 'message' is used for similar use cases, but also for > radically different ones, including those where several related > messages are displayed in quick succession (a notable example is > "Foo..." followed by "Foo...done"), or where a message is left in the > echo area indefinitely if no input event arrives. Crucially, Lisp > programs do not tell 'message' which use case is required; instead, > the following calls to 'message' or other events produce the required > effects. To produce the same effect with minibuffer-message will > require too many changes all over the place. >=20 > So I think it is simply wrong to call minibuffer-message instead of > 'message'. There are too many different behavior aspects. Several > examples were already given, including debug-on-message. One other > aspect that I just bumped into is recording messages in the *Messages* > buffer: minibuffer-message never did that, until a recent (and > undocumented) change, also related to attempts to fix messages > overwriting y-or-n-p prompts, so now we have one more incompatible > change in minibuffer-message's behavior waiting to bite us down the > road. >=20 > Therefore, I suggest to take a step back and discuss a better solution > for these problems. +1 I couldn't agree more. In fact, I said all of that in earlier messages here. > The original problem was, AFAIU, that various minibuffer prompts > become obscured by echo-area display of messages. So one possible > solution is to modify the subroutines of 'message', e.g., > set_message_1, to detect the conditions of the minibuffer being > active, and insert the contents of the minibuffer into the echo-area > buffer before the message text. Does anyone see problems with this? I don't think that's a great approach. It's not about whether the minibuffer is active. As a useful first approximation for approaching these problems, perhaps just assume that the minibuffer is _always_ active. There's always the possibility that some minibuffer interaction is in progress. Now, how to deal with some other interaction that (fairly) wants to jump in and interrupt? That's the question - whether that's a report from an async process or a new confirmation dialog, or whatever. In general, I think such other interactions should be the focus of our fixes. For any such: should it maybe be modal? Should it maybe report elsewhere (e.g. in some popup buffer)? Does it need to be logged, and if so should that maybe be elsewhere than in `*Messages*'? Focusing on reports by async operations and dialogs (e.g. confirmation dialogs) that either should be modal or should happen otherwise than by simply reading a key/char, would be a good start, I think.