RE: Use of minibuffer-prompt face when minibuffer is not involved

[Drew Adams <drew.adams@oracle.com>]

> > > The question raised for emacs-devel by this thread
> > > is whether non-minbuffer prompting should have a
> > > face, and if so, which face.
> >
> > My answer was to this question.  Let me repeat it to make it clear:
> > the difference between minibuffer prompts and
> > non-minibuffer prompts should be a purely internal one.
> 
> And I agree 100%.  I think it's a grave mistake to try to tell the
> user via faces whether some prompt/text is in the active minibuffer or
> not.  That just confuses the user with no real gain.
> 
> Active minibuffer is an internal detail.  I wish it didn't exist at
> all, but our implementation forces us to have it.  Exposing that to
> users is exactly the wrong idea.

Active minibuffer is in _no_ way "an internal detail".

It's about users knowing that the minibuffer is available
for editing.

And it's about users knowing that the minibuffer is then
the _only_ place/way to input their response.  If it has
lost focus (e.g. by clicking another frame or by other
interactions with Emacs) then they need to refocus it to
reply to the minibuffer prompt.

There is a world of difference - user-observable - between
`read-char' (e.g. `y-or-n-p'), which takes no account of
focus, and reading input from the minibuffer.  And yet the
difference is sometimes not obvious to users.  Yes, a big
difference but not necessarily obvious.

In fact, it would be better in general if we made it
more obvious when the minibuffer is active (as opposed
to the same space being used as the echo area).

With my standalone minibuffer (separate frame) I do that
by shading the frame background differently.  And I do
the same thing (but with a different shade) to indicate
that Isearch is active in that same area.

"Grave mistake"?  Why do you say so?  (No reason given.)

We (since Emacs 22, at least) now provide two different
faces for the mode-line, to show which window is active
(selected) - which has the focus.  This is very similar:
the minibuffer is a buffer in a window.  Users should
clearly see when it is focused for input ("active").

More generally still, when it comes to faces and text
properties, users deserve control - that's not something
to be imposed "internally".

No argument has been given yet supporting _why_ this
should be considered "internal".  Just two opinions
strongly proclaiming that it _is_ an internal detail.
Why do you think so?

The behavior difference is user-observable.  It should
be easily user-controllable.