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

[Drew Adams]

> This is not a big problem. But minibuffer is a
> basic UI of emacs. If it always has these bugs, 
> users may think that minibuffer is not a good 
> design.

The minibuffer does _not_ "have these bugs".
The problem is not the minibuffer.

The problems are (1) asynchronous reporting
that simply fires off a `message' blindly and
(2) read-key interaction misused for important,
essentially modal dialog, which, if during a
minibuffer interaction, can be problematic.

Emacs should provide other, safer ways to
report status or impose a separate, modal
dialog - ways that don't interfere with the
minibuffer or the echo area.

`message-box' and similar might be a start.
But the behavior should be loggable, and it
should be manipulable by program in various
ways (prompting, whether modal, etc.), and
it should be customizable by users.

And developers should then be encouraged to
change any existing code that provides async
reporting or intermediate `y-or-n-p'-style
dialogs to use the new constructs.

At least those who use such things should be
made aware that if they interrupt ongoing
interactions then they can cause trouble.
___

And for the record, I disagree with simply
automatically converting `message' behavior
to `minibuffer-message' behavior in any
systematic way.

And I disagree with replacing `read-key'
behavior for code like `y-or-n-p' with
some read-from-the-minibuffer behavior in
any systematic way.

Some given uses of these things might be
misguided and could be switched to using
`minibuffer-message' - i.e., case by case.
I'm not against `minibuffer-message' - it
has its uses.  But its uses mainly involve
providing feedback about the ongoing
minibuffer interaction - not reporting an
outside event.

One of the demonstrations of the "dangerous
problem" was from Juri changing the value of
variable `dired-deletion-confirmer' (which
is _not_ a user option) from `yes-or-no-p'
to `y-or-n-p', and then pointing to a
resulting possible loss of user data.

Well, duh - don't do that.  That variable is
there presumably for possible use by code in
a context where the deletion dialog is sure,
and controlled in some way.

Many users seem to have chosen to just
replace `yes-or-no-p' with `y-or-n-p, e.g.
by aliasing.  I think this is a practice
that should be discouraged, or at least
shouldn't be encouraged.  Code that uses
`yes-or-no-p' should be able to depend on
its response not getting lost.  Blindly
substituting `y-or-n-p' is a bad idea, IMO.

Like the problem of async reporting, reading
a key/char can be problematic.  Emacs can
hopefully come up with additional ways,
better in some contexts, to prompt for a key
that reduce or eliminate the problem.  But
foregoing quick key/char reading by forcing
use of the minibuffer is a bad "fix".

Yes, there is a _real_ problem to be solved.
There may even be more than one problem.
(Async reporting is not the same as reading
a key/char.  The fixes are not necessarily
the same.)

But no, the one-size-fits-all approach taken
so far is not a good solution, IMO.

It screws the minibuffer - an editable
buffer allowing complex user interactions.

It screws with the difference, when using
the minibuffer, between (1) the behavior of
`message' (use the echo area, temporal
interruption dismissable by typing) and (2)
that of `minibuffer-message' (append output
to the minibuffer input, no interruption -
interfere spatially, not temporally).

Each of those, minibuffer-message' and
`message', has its particular uses and
behavior while the minibuffer is active.
And the various key/char-reading functions
also have their particular uses.  None of
these should be tossed or stifled.

Throwing all that to the wind, neutering
it with a one-size-fits-all behavior, is a
step backward.  We should fix the various
problems carefully - very carefully, and
in context.

Don't start with the supposition that the
minibuffer is the problem.  It's code that
interferes with a minibuffer interaction
that's the problem.

Whether, when, and how to interrupt an
existing dialog is the question.  The
answer is, "it depends".

Emacs should be able to let a minibuffer
interaction coexist safely with async
reporting or key/char reading - without
just stuffing in timeouts and tossing
everything into `minibuffer-message'.

In some cases an interaction (user dialog)
may need to be _modal_ - finish reading a
confirmation before allowing other action.
This is about such an interaction coming
about while another, minibuffer, dialog
already exists.

In other cases that's not necessary.  The
calling code that prompts for what should
be a modal interaction should DTRT.  It's
not up to another, minibuffer, interaction
to protect against such disruption.
___

Just one opinion - expressed in more detail
in this and some other bug threads.

The fact that this "fix" is spread over
several bug threads, dealing with different 
problematic behaviors, is perhaps a sign
that this approach is not TRT.

And such a far-reaching change should, I
think, have been discussed in emacs-devel.

Instead, in these bug threads we've been
told that this is only a minor, localized
change that will not affect 3rd-party code.
That does _not_ seem to be the case, and I
don't see how it could be.