From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: HaiJun Zhang Newsgroups: gmane.emacs.bugs Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change Date: Thu, 12 Dec 2019 12:33:09 +0800 Message-ID: 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> <83eexcax6b.fsf@gnu.org> <835zinbkct.fsf@gnu.org> <83zhfyakwd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="5df1c30a_34cc3acf_422" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="59543"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org, monnier@iro.umontreal.ca, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 12 05:34: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 1ifGB3-000FKe-Kt for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Dec 2019 05:34:13 +0100 Original-Received: from localhost ([::1]:54338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifGB1-0004UY-Re for geb-bug-gnu-emacs@m.gmane.org; Wed, 11 Dec 2019 23:34:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48438) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifGAu-0004UQ-OF for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2019 23:34:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ifGAs-0005qO-QS for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2019 23:34:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52933) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ifGAs-0005q4-LJ for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2019 23:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ifGAs-0005bL-Hj for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2019 23:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: HaiJun Zhang Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Dec 2019 04:34: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.157612521221490 (code B ref 38457); Thu, 12 Dec 2019 04:34:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 12 Dec 2019 04:33:32 +0000 Original-Received: from localhost ([127.0.0.1]:58906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ifGAN-0005aX-Ue for submit@debbugs.gnu.org; Wed, 11 Dec 2019 23:33:32 -0500 Original-Received: from mail-oln040092254098.outbound.protection.outlook.com ([40.92.254.98]:6296 helo=APC01-PU1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ifGAK-0005aE-Jk for 38457@debbugs.gnu.org; Wed, 11 Dec 2019 23:33:30 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mr8e0uiV7mbHy1HtWWVWNCE5P7oqP3f2FO349oP1qM8TjycMhDndfNVnj2Nhf/EOVJIGTr/0BSv7PuT9DoUWMAkBB93l8PmxvCuQBZ89DFnF+HZwbC2EiC63EeGFHeg1gEbRdnha8jXDDkGYeiJpJcHTAJCcmcnGzxNq1LMYPr/byDMTsnpCsH5zGR2ObcoQjqgNfkWKGYCw+Gz4mW6HLlw9EDTSKhRZgS0Tv+sMw/wt/CTMMJ6FJGsNVan+sjq2um01MW4XViZRLA64YDJAILsV4P7GmH2AA4HiNgSLC83XIrBB825Zjk4TQX3ypNNDT3HmgzkmmQdPw8vM+QCmvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=72+1FbBMP0LbYs8o5XvaL5SyS7JMIjbjbPEswvYyo8A=; b=IY7BNg4ncuO/EPh3h/AUcpQqYxwHX5wwsB191oUZc6kaXXz907Cj1wlqEa7Q/9WfkOlr5Z9mQSlcfZVleKwaVSIan3Ue2syIx9ymxaYBbyCeTQiRnrUT7CIdDhTEkzvw7ZrES9uNFqbfmNE6WLjyEYtYIOCR0bvxJtFJw5Yg2AtStnY5z6mkr5GskBMfxZzvxV5Qt1+p9+gQ3GgRA0Voa7tixzBCwgNFP6b08StBywvFlMOQpAgUc1sykyArG8QgRa8NlHbeLlm1xNrMCG4nbnXMpc//tOCt4Emcieju8ZnikbEUHO66lwXF1q7vFgcFR73CNnDALbwUjenE5JknUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=outlook.com; dmarc=pass action=none header.from=outlook.com; dkim=pass header.d=outlook.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=72+1FbBMP0LbYs8o5XvaL5SyS7JMIjbjbPEswvYyo8A=; b=ZFNGrPjS5f/fNkIe5eFv03bFEQQKVZnsflVDbzR2cFOfYrocmsPnABDeozMOza81WooXstnyrdonY1YajxhWMmzlPJ4UEZjQjIZAEiqzi33gogf5n2QivoMO6DDnf9muinPlVch6R43NJTSFMvoTuDRYtWrT5WUro+4E906OoO+BBlikWHcEMrDz9hSKCJxqSb7v89Y3v2Y4XOiiFJKP9hTFEr7GgZtCXXxlYMRHctCD3uPC/vNLJU33qzByvDEQxB1ltxiDzMIo9+KvIlatkl9lGF9u8bUZjCOixWSWI1HQepdfuaLNvFN2UKAoAnWr0U+cuG0BE7/F++Vtev5h0w== Original-Received: from HK2APC01FT023.eop-APC01.prod.protection.outlook.com (10.152.248.54) by HK2APC01HT241.eop-APC01.prod.protection.outlook.com (10.152.249.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15; Thu, 12 Dec 2019 04:33:20 +0000 Original-Received: from PS1PR03MB3606.apcprd03.prod.outlook.com (10.152.248.57) by HK2APC01FT023.mail.protection.outlook.com (10.152.248.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15 via Frontend Transport; Thu, 12 Dec 2019 04:33:20 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:4081D10F09D3DABBC6111FD9B22D83652DB9EBB0CFFD61AC9FE6F0B64E5EDDD1; UpperCasedChecksum:F7122F68C0964124CD773565D8CF4ED1D852AF244FB1190964C9F748D9CC0541; SizeAsReceived:9455; Count:48 Original-Received: from PS1PR03MB3606.apcprd03.prod.outlook.com ([fe80::b05a:28e4:205a:d7d4]) by PS1PR03MB3606.apcprd03.prod.outlook.com ([fe80::b05a:28e4:205a:d7d4%5]) with mapi id 15.20.2538.016; Thu, 12 Dec 2019 04:33:20 +0000 In-Reply-To: <83zhfyakwd.fsf@gnu.org> X-Readdle-Message-ID: c2dd69c1-1cf3-46b1-959c-e2ae7ccb7083@Spark X-ClientProxiedBy: HK0PR03CA0115.apcprd03.prod.outlook.com (2603:1096:203:b0::31) To PS1PR03MB3606.apcprd03.prod.outlook.com (2603:1096:803:4e::17) X-Microsoft-Original-Message-ID: Original-Received: from [192.168.1.103] (1.199.222.221) by HK0PR03CA0115.apcprd03.prod.outlook.com (2603:1096:203:b0::31) with Microsoft SMTP Server (version=TLS1_2, cipher=) via Frontend Transport; Thu, 12 Dec 2019 04:33:18 +0000 X-Readdle-Message-ID: c2dd69c1-1cf3-46b1-959c-e2ae7ccb7083@Spark X-Microsoft-Original-Message-ID: X-TMN: [u9b4KjKSs+jmcBNHMa503dMu1ZPoy2kY] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 698de079-6dc3-4182-578c-08d77ebc6a5c X-MS-TrafficTypeDiagnostic: HK2APC01HT241: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /UW979qT6RDXAtdFwQZlY/fIW20AltY6cnPOLSV7ebu7Qs6LsF2yPjU5u8ji2/4IO8P7huitmztoeLtXzZ1I2geZbjbaJ2v1vQwXg9ctBhoLkyBi9rEjBrYVp2E3G0PrjdhZk/4W52f8N6k+UNVTnTGdMZTB8g7yEKCiZiWobiKGmYeGzv26BrNUMDRB/F8s X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 698de079-6dc3-4182-578c-08d77ebc6a5c X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2019 04:33:20.2630 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT241 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:173201 Archived-At: --5df1c30a_34cc3acf_422 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2019=E5=B9=B412=E6=9C=8812=E6=97=A5 +0800 AM12:26=EF=BC=8CEli Z= aretskii =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A > In general, people who set resize-mini-windows to nil are always in > danger of seeing only part of the message Emacs displays. > =46or the combination of prompt and message, there is a worst case: the m= essage may never be displayed because no space in minibuffer window. The = user may never notice it. > > Another question: > > When emacs displays combination of the prompt and the message, if use= r input something, doesn=E2=80=99t the > > message disappears=3F > > It does disappear, and the prompt remains. Again, lime with the > current master. > When user is inputing something in minibuffer, I think there is hardly an= y message so important to let user pause the inputing and wait for the ne= xt message, except they are BBC news. The importance levels for me: =C2=A0 =C2=A0 (1) Inputing in minibuffer =C2=A0 =C2=A0 (2) Inputing in buffer window =C2=A0 =C2=A0 (3) Messages in minibuffer window I think messages(In (3)) should not disturb (1). Because they are so less= important. And when user is busy editing in (2), he may never notice messages in min= ibuffer because they are cleared quickly. So important messages should no= t use minibuffer. They should use mode-line or something else. One example for using mode-line: Magit is a git tool in emacs. When push with magit, it display =E2=80=9Cp= ush=E2=80=9D in mode-line and clear it when done. > > This is what the current code does, > > > > The current code doesn=E2=80=99t display the message transiently. It = displays it forever. > > By =22the current code=22 I meant the current master branch. I meant the code before minibuffer-message is added. > There, the > message is displayed for 2 sec, and then disappears, even if the user > didn't press any key. Which is different from how 'message' behaves > when there=E2=80=99s no prompt. I like this behaviour. There are two sub-behaviours: =C2=A0 =C2=A0 (1) Display the combination of prompt and message. After 2s= , display prompt only =C2=A0 =C2=A0 (2) Display message only. After 2s, back to display prompt = only. The problem(for UI only) with (1) is that there is a worst case mentioned= above (when resize-mini-windows is nil). But it is well for almost 99%. Both of them are OK to me. I just think that (2) may be more simple and m= ay have less conflicts with other packages. By the way, ivy (a popular package for emacs) uses (2). It works in minib= uffer. When a message comes, it displays the message. After a moment, it = clears the message and restores its UI. > > > User needs to press a key to > > restore to the prompt. Is this a bug=3F > > No, I don't think it's a bug. If some Lisp program displays a message > and doesn't follow it with a nil message, it means that Lisp program > =5Fwants=5F the message to remain on display until the user dismisses i= t. > The current behaviour in emacs-26(and the master branch before minibuffer= -message is added) is that emacs hides the prompt and displays the messag= e forever. Most lisp programs don=E2=80=99t display the nil message. So t= he prompt will not be resotred automatically. I think it is hard for lisp programs to display the nil message(It may ha= ve to setup a timer). So most of them don=E2=80=99t do this. I don=E2=80=99= t know one of them. And I think inputing in minibuffer or editing in buffer is much more impo= rtant than these messages. If the message is too important, it should go = to mode-line or else. > What indicator=3F > See the example of magit above. > (And I don't understand why we are arguing, since you just said in > another message that you liked my proposal=E2=80=A6) Yes. I like your proposal that message do these things internally. Becaus= e the input prompt should always be considered, so all these things can b= e done in =E2=80=98message=E2=80=99. Then it seems that we don=E2=80=99t = need another api(like minibuffer-message)=3F Is the UI of your proposal like this=3F (1) Display combination of the prompt and the message with no timeout. (2) If user inputs something, the message is cleared and only prompt is d= isplayed. It is also simple. I like it. The last question: What is the use of minibuffer-message-timeout. It is defined in C. When d= oes it take effect=3F --5df1c30a_34cc3acf_422 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=E5=9C=A8 2019=E5=B9=B412=E6=9C=8812=E6= =97=A5 +0800 AM12:26=EF=BC=8CEli Zaretskii <eliz@gnu.org>=EF=BC= =8C=E5=86=99=E9=81=93=EF=BC=9A
In general, people who= set resize-mini-windows to nil are always in
danger of seeing only part of the message Emacs displays.


For the combination of prompt and message, there is a wor= st case: the message may never be displayed because no space in minibuffer = window. The user may never notice it.


Another question:
When emacs displays combination of the prompt and the message, if user inpu= t something, doesn=E2=80=99t the
message disappears?

It does disappear, and the prompt remains. Again, lime with the
current master.


When user is inputing something in minibuffer, I think there is hardly any = message so important to let user pause the inputing and wait for the next m= essage, except they are BBC news.

The importance levels for me:

    (1) Inputing in minibuffer
    (2) Inputing in buffer window
    (3) Messages in minibuffer window

I think messages(In (3)) should not disturb (1). Because = they are so less important. 
And when user is busy editing in (2), he may never notice= messages in minibuffer because they are cleared quickly. So important mess= ages should not use minibuffer. They should use mode-line or something else= . 

One example for using mode-line:
Magit is a git tool in emacs. When push with magit, it di= splay =E2=80=9Cpush=E2=80=9D in mode-line and clear it when done.


This is what the curre= nt code does,

The current code doesn=E2=80=99t display the message transiently. It displa= ys it forever.

By "the current code" I meant the current master branch.  

I meant the code = before minibuffer-message is added.


There, the
message is displayed for 2 sec, and then disappears, even if the user
didn't press any key. Which is different from how 'message' behaves
when there=E2=80=99s no prompt. 

I like this behaviour. There are two sub-behaviours:

    (1) Display the combination of prompt and m= essage. After 2s, display prompt only
    (2) Display message only. After 2s, back to= display prompt only.

The problem(for UI only) with (1) is that there is a wors= t case mentioned above (when resize-mini-windows is nil). But it is well fo= r almost 99%.

Both of them are OK to me. I just think that (2) may be m= ore simple and may have less conflicts with other packages.

By the way, ivy (a popular package for emacs) uses (2). I= t works in minibuffer. When a message comes, it displays the message. After= a moment, it clears the message and restores its UI.



User needs to press a = key to
restore to the prompt. Is this a bug?

No, I don't think it's a bug. If some Lisp program displays a message
and doesn't follow it with a nil message, it means that Lisp program
_wants_ the message to remain on display until the user dismisses it.

The current behaviour in emacs-26(and the master branch b= efore minibuffer-message is added) is that emacs hides the prompt and displ= ays the message forever. Most lisp programs don=E2=80=99t display the nil m= essage. So the prompt will not be resotred automatically.

I think it is hard for lisp programs to display the nil message(It may have= to setup a timer). So most of them don=E2=80=99t do this. I don=E2=80=99t = know one of them.

And I think inputing in minibuffer or editing in buffer i= s much more important than these messages. If the message is too important,= it should go to mode-line or else.


What indicator?

See the example of magit above.

(And I don't understan= d why we are arguing, since you just said in
another message that you liked my proposal=E2=80=A6) 
Yes. I like your proposal that message do these things internally. Because = the input prompt should always be considered, so all these things can be do= ne in =E2=80=98message=E2=80=99. Then it seems that we don=E2=80=99t need a= nother api(like minibuffer-message)?

Is the UI of your proposal like this?
(1) Display combination of the prompt and the message wit= h no timeout.
(2) If user inputs something, the message is cleared and = only prompt is displayed.

It is also simple. I like it.


The last question: 
What is the use of minibuffer-message-timeout. It is defi= ned in C. When does it take effect?


--5df1c30a_34cc3acf_422--