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

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: monnier@iro.umontreal.ca,  38457@debbugs.gnu.org
> Date: Fri, 13 Dec 2019 01:07:39 +0200
> 
> > But 'message' always behaved this way, so using a timeout is change in
> > behavior, whereas my proposal leaves the behavior unchanged, and just
> > makes the prompt still visible, so it avoids confusing the user.  User
> > confusion was the main issue that triggered the series of changes we
> > are discussing, and it will be resolved by my proposal.
> 
> But 'minibuffer-message' never behaved this way because it's very annoying
> when messages remain indefinitely in the minibuffer, and a key is needed
> to be pressed to flush mostly useless messages away.
> 
> Messages in the echo-area and messages in the minibuffer are different
> things for user interaction.

That is exactly my point: these two APIs are very different in the
behavior they provide and support.  It follows that calling
'minibuffer-message' from 'message' under some circumstances is a
radical change in behavior.  Such radical changes are fine when we
introduce radical new UI features, but the changes we discuss here
were made to fix bugs.

I'm saying we can fix those bugs without introducing radical new
features, which AFAIU are not yet finished, and will probably require
many more changes to get them right.  We should limit ourselves to
fixing the most annoying bugs/misfeatures, and leave the more radical
changes for a future major release after Emacs 27.

> OTOH, such messages as "Compilation finished" would significantly impact
> editing of the minibuffer's content in a negative way when displayed
> permanently.

When the user is using the minibuffer, the message is very unlikely to
stay there indefinitely, since user interaction implies user input,
which will remove the message.  OTOH, leaving such messages until the
next input event will let the user determine when will the message be
removed, whereas using a timeout takes that control from the user.
What if the message is important, but the user takes a long time to
read it, or is distracted by something?

> >> If someone wants the message to hang out indefinitely in the minibuffer,
> >> this is possible, minibuffer-message-timeout is configurable:
> >
> > That is a user option, so we cannot change it globally.  We could bind
> > it temporarily, but how can we know which value to use in each and
> > every use case, on the level where you call minibuffer-message from
> > inside 'message'?
> 
> I meant that it should be possible to customize the user option.

And I was talking about the default operation.  The default operation
should be reasonable.

> > No, my suggestion is not to remove the message automatically at all,
> > i.e. leave this aspect of 'message's behavior unchanged.  The message
> > text will be removed when either the user types something, or when
> > some Lisp calls 'message' again to clear the message text.
> 
> It should take into account a user option that specifies the timeout
> after which the message should be removed using a timer.
> 
> If you want to leave the message indefinitely by default that's fine,
> but the users should have an option not to suffer from the
> default behavior that you propose.

We already have that default behavior.  We had it for eons.  I just
propose not to change it yet, because the alternative means a radical
change in the UI and many changes in low-level infrastructure whose
full extent we don't know yet.  The way you've decided to solve these
problems practically requires us to continue making these radical
changes, and that will delay the Emacs 27 release for many moons.

And the timing of removal of the message is just one aspect.  There
are others: the logging in *Messages*, the debug-on-message feature,
and I'm sure we will discover more of them.  The only "easy" way of
solving these is to make 'minibuffer-message' do that stuff as well,
which means incompatible changes in 'minibuffer-message', and is
likely to raise more issues, which will delay Emacs 27 even more.  All
that is the consequence of the basic fact that we both agree on:
'message' and 'minibuffer-message' are two very different beasts, so
making one call the other has got to cause complications.

If we want to release Emacs 27.1 soon (and we should), we cannot
continue on this path, we must find a reasonable way of delaying the
more radical parts of these changes to Emacs 28.