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

[Juri Linkov]

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

I'd like to add that the biggest drawback of sit-for is that
no message is displayed when input is available like is in e.g.
do-after-load-evaluation after start, or when the user is typing in
the minibuffer, the user might miss an important message.

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

I agree that a new function needs to be created, and agree
not to call minibuffer-message from 'message'.

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

Since a new near-clone of minibuffer-message is needed, and
we agreed to not call minibuffer-message from 'message',
I reverted all previous changes.

Now a new feature could be implemented from scratch.

I created a new ELPA package attached below that
implements this feature.  So everyone who like it
can use it even after release.  Also this package
could be used for experimentation to find the best way
to use it, that later could be moved to core in Emacs 28.

I think now we have no moral right to delay the Emacs 27 pretest
anymore.

minimess.el
Description: application/emacs-lisp