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

[Juri Linkov]

>> > That would mean bring back all the problems for which these changes
>> > were made.  So it would be the worst of all worlds, and thus makes
>> > very little sense to me.
>> 
>> 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.
>
> 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?

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':

      if (minibuf_level
          && !NILP (echo_area_buffer[0])
          && EQ (minibuf_window, echo_area_window)
          && NUMBERP (Vminibuffer_message_timeout))
        {
          /* Bind inhibit-quit to t so that C-g gets read in
             rather than quitting back to the minibuffer.  */
          ptrdiff_t count = SPECPDL_INDEX ();
          specbind (Qinhibit_quit, Qt);

          sit_for (Vminibuffer_message_timeout, 0, 2);

          /* Clear the echo area.  */
          message1 (0);
          safe_run_hooks (Qecho_area_clear_hook);

          unbind_to (count, Qnil);

          /* If a C-g came in before, treat it as input now.  */
          if (!NILP (Vquit_flag))
            {
              Vquit_flag = Qnil;
              Vunread_command_events = list1i (quit_char);
            }
        }

This code looks very like 'minibuffer-message', and still uses 'sit_for'.

>> > And in any case, minibuffer-message already behaves differently: it
>> > logs the message in *Messages*, something it never did and is not
>> > documented, and you suggested another change, to make it start the
>> > debugger per debug-on-message.  These change behavior of any direct
>> > callers of minibuffer-message in incompatible ways, something I don't
>> > think we have a good reason to do.
>> 
>> I see no reason not to change minibuffer-message.  But if you think
>> it should never change, let's create a duplicate function
>> message-in-minibuffer.
>
> Fine with me, as long as the duplicate is an internal function.  Maybe
> that new internal function should be invoked from message3_nolog
> instead, btw?  That would remove the need to duplicate the
> functionality of message_dolog.
>
> 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.