For the combination of prompt and message, there is a worst case: the message may never be displayed because no space in minibuffer window. The user may never notice it.
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 message, except they are BBC news.
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 messages 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 display “push” in mode-line and clear it when done.
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.
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’s no prompt.
I like this behaviour. There are two sub-behaviours:
(1) Display the combination of prompt and message. 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 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 may have less conflicts with other packages.
By the way, ivy (a popular package for emacs) uses (2). It 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 before minibuffer-message is added) is that emacs hides the prompt and displays the message forever. Most lisp programs don’t display the nil message. 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’t do this. I don’t know one of them.
And I think inputing in minibuffer or editing in buffer is 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 understand why we are arguing, since you just said in
another message that you liked my proposal…)
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 done in ‘message’. Then it seems that we don’t need another api(like minibuffer-message)?
Is the UI of your proposal like this?
(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 displayed.
It is also simple. I like it.
The last question:
What is the use of minibuffer-message-timeout. It is defined in C. When does it take effect?