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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  38457@debbugs.gnu.org,
>   stephen.berman@gmx.net
> Date: Mon, 09 Dec 2019 08:43:11 +0100
> 
> > As it turns out, not any command, because "M-x" and "C-x C-f" also use
> > the minibuffer.
> >
> > And the original bug reports definitely were about y-or-n-p.
> 
> That's true, but I think the way it works now is a huge improvement.
> Just about whatever I'm doing now, asynchronous messaging does not
> overwrite prompts/M-x actions, and that's really nice.
> 
> The bug reports may have been about y-or-n-p, but it's a general problem
> that's been solved in a general way now.  Reverting this would be a step
> in the wrong direction.

I didn't suggest to revert it, I suggested to modify it so that we
could selectively enable the feature where it doesn't have adverse
side effects.  By contrast, what we have now summarily enables the
feature for every use of the minibuffer, and we will then have to
somehow disable or augment it in every case where it does have adverse
side effects.  We already have 2 bug reports about it for 2 separate
packages, and we cannot leave them unsolved.  I'm sure this is just
the tip of a very large iceberg.

How do you propose we move forward?  You think we should install the
timer proposed by Juri instead?  That would make this change even more
invasive than it already is, and will again affect every use of the
minibuffer, and then some.  And I have no doubt that the delay in
removing the message is not the only side effect of the change in how
'message' now works, it's just the first one we noticed.  This is a
sure way to delay Emacs 27 even further.

We are developing Emacs 27 for more than 1.5 years.  We need to start
its release cycle very soon, and we should start from a stable code
base.  I have been asking people since July to avoid putting
destabilizing changes on master.  The change in 'message' destabilized
what we had before, and the proposed timer will destabilize it even
more.  How long do we want the Emacs 27.1 pretest to last? a year?
more?

We could also revert the change now and reapply it after the emacs-27
branch is cut.  That would mean the original use case with y-or-n-p
will not be fixed until Emacs 28.  Personally, I think it would be a
pity to leave that issue unsolved in Emacs 27, but if I cannot get us
to agree to any other solution, maybe that's what we should do.

More generally, I need everyone's help in making Emacs 27.1 happen
soon enough.  I cannot do it if people discount my gut feelings about
Emacs stability when those gut feelings are strong enough for me to
object to changes.  It's unfair to expect me to agree to something
when every bit of my experience screams that it's wrong.  If I cannot
get people to bear with me even on rare occasions when I have those
gut feelings, I guess I'm unfit for the job, and someone else should
take over.