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

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> 
>> > So please try to find a simpler fix for this problem, one that doesn't
>> > involve a timer.
>> 
>> This is the simplest and the safest solution.
>
> The simplest solution would be to prevent dabbrev-expand from
> displaying the message in the first place; there are conditions for
> that which evidently the new implementation somehow triggers.
>
>> I wanted to implement it earlier but had no time before.  I see no
>> problems with it.
>
> Let's not rock the boat too much so close to the release cycle because
> of a very minor problem which caused these changes.  You may not see
> any problems with it now, but I'm certain we will bump into numerous
> problems very soon if we make such significant changes in this
> infrastructure, which is used everywhere in Emacs.

Mmm, as you say, the message infrastructure is used everywhere in Emacs,
and it has received significant changes in aa89c84e00d.

I think the regression Stephen noticed is more widespread than just
dabbrev-expand: e.g. TRAMP is also affected[1].  Does it make sense to
address each symptom individually?  Were dabbrev, TRAMP, and possibly
others wrong to assume that they could call (message …) without causing
2-second delays?

NB: I am not saying that Juri's initial patch is the simplest nor the
safest.  It just seems to me that aa89c84e00d has already "rocked the
boat" quite a bit, and addressing this specific bug report by tweaking
dabbrev-expand will only take care of the tip of the iceberg, to
continue the nautical metaphor…


[1] C-x C-f /ssh:localhost: RET

    ⇒ This hangs for 10 seconds unless the user furiously spams some
    command (e.g. C-n), as each of the following message takes 2 seconds
    to disappear:

    > Tramp: Opening connection for localhost using ssh...
    > Tramp: Sending command ‘exec ssh   -o ControlMaster=auto -o 
ControlPath='tramp.%C' -o ControlPersist=no -e none localhost’
    > Tramp: Waiting for prompts from remote shell...done
    > Tramp: Found remote shell prompt on ‘localhost’
    > Tramp: Opening connection for localhost using ssh...done

    I haven't reported this as a separate issue yet, because I am
    assuming that both bugs are caused by recent changes in message and
    should be fixed there…