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

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: 38457@debbugs.gnu.org
> Date: Sun, 15 Dec 2019 01:10:58 +0200
> 
> > That leaves open the issue of the default value of
> > minibuffer-message-timeout.  I don't think we can change it, because
> > it affects minibuffer-message as well.  But we could have a new
> > option, which would affect only the duplicate function you mention
> > below.  If the new option by default makes the message stay until the
> > next one or until user input, I think this would be an okay solution
> > that satisfies everyone, at least for Emacs 27.
> 
> The main problem with 'minibuffer-message' is that it uses 'sit-for'.
> If a new function will use the same 'sit-for' to detect when input is
> available, then it will bring the same problems.  Here's is an example
> of the problems it causes: I call 'select-window' from 'post-command-hook'
> to select an output window, but 'sit-for' delays selecting the window
> for 2 seconds until 'execute-extended-command' finishes displaying
> the message "You can run the command `%s' with %s" using 'sit-for'.
> The output window becomes selected only after 2 seconds because
> a customized function in 'post-command-hook' doesn't run earlier
> than returning from 'sit-for' in 'execute-extended-command'.
> 
> 'sit-for' is used in many places, but it's inappropriate for these tasks.
> What is a possible replacement for 'sit-for'?  For a delay of specified
> seconds, one solution is to run a timer.  But how to replace another
> aspect of 'sit-for', namely an ability to stop when input is available?

What I had in mind was to go with your idea, viz.:

> Then your proposed implementation should be activated when
> minibuffer-message-timeout is set to a non-nil value.
> Otherwise, when it's a number, it should use the timer.

IOW, introduce a new option, which will affect the new function we
were talking about, a near-clone of minibuffer-message (and will not
affect minibuffer-message itself).  When that new option's value is
not a number, the near-clone of minibuffer-message should not call
sit-for at all; and when that value is a number, use a timer to remove
the message after that many seconds if no input arrives before that.

In any case, I thought we agreed not to call minibuffer-message from
'message', but define a new function, similar but not identical to
minibuffer-message (what I call a "near-clone").  And
minibuffer-message-timeout should not affect that new function, it
should be a separate option.

> There is a need for a hook that would be called when input is available.
> Maybe such hook already exists, I don't know, I searched but found only
> 'echo-area-clear-hook' that is used in this code in 'command_loop_1':

Do we still need such a hook if the idea above is implemented instead?

> > Assuming you agree, once this change is made, some of the recent
> > changes related to these issues should be reverted.  Can I ask you to
> > review those related changesets and publish a list of those which need
> > to be reverted or augmented?
> 
> Here's is a list of related changesets:
> 
> 8693611136
> aa89c84e00
> 54c792ece6
> 
> Please revert them if you want.

Thanks.  Let's revisit these after the implementation of the
minibuffer-message's clone is finalized, so that we could know which
ones of these are still needed and which aren't.