bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters

[martin rudalics]

> I dug into yes-or-no-p until I came across `read_minibuf()'; is this the
> code you are referring to?

It is.

> If one were to fix the issue of y-or-n-p hardcoding the face property,
> what would be the best way to go?
>
> 1. Make a C DEFUN out of this snippet, and have it called by
>     `read_minibuf()' and `y-or-n-p'.
>
> 2. Re-implement this snippet as an Elisp defun, and have it called by
>     `read_minibuf()' and `y-or-n-p'.
>
> 3. (Re-implement this snippet within `y-or-n-p'.)
>
> (FWIW, the attached patch seems to work as a workaround, but I assume
> solutions 1 or 2 would be better, by virtue of reusing code)

By design, 'yes-or-no-p' and 'y-or-n-p' are kept apart to avoid that
people use the latter for more "crucial decisions".  Part of this
distinction is that 'y-or-n-p' is asked in the echo area, so applying
'minibuffer-prompt-properties' would be conceptually inappropriate.
Obviously, applying 'minibuffer-prompt' is just as inappropriate (that
face is part of 'minibuffer-prompt-properties') but that's a decision
that has been made long ago.

So although I'd vote for a solution like the one you propose in your
patch, any decision in this area is subtle and should be approved by
others first.  Also because we'd then have to decide what to do with
other clients of the 'minibuffer-prompt' face like 'read-char-choice'
or the ones in isearch.el.

martin