Use of minibuffer-prompt face when minibuffer is not involved

[Kévin Le Gouguec]

Hello Emacs,

For some reason[1], I found myself wanting to add text properties to
y-or-n-p's prompt.  This is currently not possible, as the prompt's
face property is hard-coded like so:

    (propertize (if (memq answer scroll-actions)
                    prompt
                  (concat "Please answer y or n.  "
                          prompt))
                'face 'minibuffer-prompt)))))

An ad-hoc fix seems simple enough[2]; further discussion with Martin
Rudalics and Drew Adams showed that:

- there are other places where this (propertize … 'face
  'minibuffer-prompt) idiom is used, such as isearch prompts and
  read-char-choice;

- these examples do not actually activate the minibuffer (AFAIU), so
  using the minibuffer-prompt face could be considered questionable.

Considering all that, what course of action do you consider worth
pursuing?

0. Do nothing. ("The face might be called minibuffer-prompt, but there
   are enough non-minibuffer uses of it that it's not worth fixing
   this inconsistency at this point.")

1. Introduce a new face named e.g. prompt, which by default would…

   1. … inherit minibuffer-prompt for "visual backward-compatibility".

   2. … differ from minibuffer-prompt to teach users the distinction
      between echo area and minibuffer.

2. Stop propertizing the prompt; no new face.

I have no horse in this race[3]; I understand both the appeal of 0
(minimize churn and UI inconsistencies during the transition), 1.1
(configurability and smooth transition), 1.2 and 2 (consistency and
pedagogy).

WDYT?


NB: the discussion on bug#35564 also touched on text properties with
tooltips; I figured the subject of (message …)'d prompts is
substantial enough that tooltips could be discussed separately, but
please make sure to check out Martin and Drew's thoughts on the matter
if this is something you want to discuss.


[1] To sum up my initial report over at bug#35564:

    - dired-do-shell-command's warning about "wildcard" characters
      annoys me, since AFAICT they may not be wildcards at all
      (e.g. they may be quoted or backslash-escaped).

    - Rather than coming up with a better warning, I toyed with text
      properties to build a prompt which highlights these characters.

    - I found out that y-or-n-p discards my prompt's text properties.

[2] See patch at bug#35564#11.

[3] Mainly I'd like to fix bug#35564.  I assume it can be fixed
    whichever way this discussion goes:

    1. either someone finds a better phrasing for Dired's warning,

    2. or the highlighted prompt implemented in bug#35564#5 is deemed
       cute enough and we decide to change y-or-n-p's (propertize …)
       into (add-face-text-property …)

       1. either locally in y-or-n-p,

       2. or in a new function which could be re-used by
          read-char-choice et al.,
          
    3. or someone enlightens me as to why Dired calling these
       characters "wildcards" is TRT, making the bug report moot.