bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38457: 27.0.50; dabbrev-expand regression due to message change


From: Eli Zaretskii
Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change
Date: Wed, 11 Dec 2019 18:26:26 +0200

> Date: Wed, 11 Dec 2019 11:59:48 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: monnier@iro.umontreal.ca, 38457@debbugs.gnu.org, juri@linkov.net
> 
>  I explained in more detail how I suggested to implement thius: by
>  inserting the minibuffer contents before the message text. What is
>  complex about that?
> 
> Because resize-mini-windows may be nil. And the message may be invisible. 

The current master has the same problem.

In general, people who set resize-mini-windows to nil are always in
danger of seeing only part of the message Emacs displays.

> Another question: 
> When emacs displays combination of the prompt and the message, if user input 
> something, doesn’t the
> message disappears?

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

>  This is what the current code does,  
> 
> The current code doesn’t display the message transiently. It displays it 
> forever.

By "the current code" I meant the current master branch.  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's no prompt.

> 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.

>  and the problem with that is that
>  some uses of 'message' don't expect the message to stay for 2 seconds,
>  and some expect it to stay forever. This information is not explicit
>  in the call to 'message', so there's no way of communicating in down
>  to minibuffer-message. 
> 
> Do you mean the scene “Foo…” followed by “Foo…done”?

That's one scenario, yes.  But it is not the only one.

> I don’t think this is a problem. These are just status which are not 
> important. And they disappears quickly
> when user is busy editing.

With the current master, it doesn't disappear quickly, it stays for 2 sec.

> And the really important ones may put an indicator on the mode-line.

What indicator?

(And I don't understand why we are arguing, since you just said in
another message that you liked my proposal...)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]