bug#25151: 26.0.50; read-char prompt does not minibuffer face

bug#25151: 26.0.50; read-char prompt does not minibuffer face

[Mark Oteiza]

Hi. From -Q:

1. M-z

The zap-to-char (hence read-char) prompt is not in the minibuffer face.

In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2016-12-07 built on logos
Repository revision: 2766c607b0b0d201be5b9b1d5eb291415e5980d8

bug#25151: 26.0.50; read-char prompt does not minibuffer face

[Drew Adams]

This raises a good question.

I guess you are suggesting that face `minibuffer-prompt'
should be used here?  If so, is that face intended to be a
prompt face in general (i.e., THE prompt face, by default)
or just a _minibuffer_ prompt face?

It might make sense for the faces for other kinds of prompt
to look the same, by default, as `minibuffer-prompt'.  (Or
it might not.)

But according to its name, face `minibuffer-prompt' is 
specific to prompting when reading input in the minibuffer.
(And that's not the case for `read-char', `y-or-n-p', etc.)

It could be decided that `minibuffer-prompt' is to be used
for prompting in general.  In that case it really should be
called something like `prompt'.

But I think it would make more sense to create a separate
face `prompt', and (perhaps) let `minibuffer-prompt' inherit
from it.

Some users might, in particular, want to see a difference
when they are prompted and reading is NOT from the minibuffer.
Functions that read characters without using the minibuffer
can confuse users, and a difference in prompt face could give
them an idea that input is being read differently.

Recently Emacs Dev decided to just add face `minibuffer-prompt'
to the prompt for `y-or-n-p'.  I'd sooner see a separate face
be used for non-minibuffer input prompting (even if the default
appearance might be the same).

bug#25151: 26.0.50; read-char prompt does not minibuffer face

[Lars Ingebrigtsen]

Mark Oteiza <mvoteiza@udel.edu> writes:

> Hi. From -Q:
>
> 1. M-z
>
> The zap-to-char (hence read-char) prompt is not in the minibuffer face.

I can reproduce this in Emacs 26.1, but not in Emacs 28, so I guess this
has been fixed in the years since this was reported, and I'm closing
this bug report.  If this is still an issue, please respond to the
debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no