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

[Kévin Le Gouguec]

Drew Adams <drew.adams@oracle.com> writes:

> I don't see any good reason why face `minibuffer-prompt'
> should be used, especially by default (users can do
> whatever they like) for situations where there is no
> active minibuffer, i.e., for prompting situations
> generally.  It should instead serve as a useful clue
> that the minibuffer is being used.  (Just one opinion.)

I'd hazard a guess[1] that this was done to make y-or-n-p and
yes-or-no-p similar from a UI point of view: they both prompt the user
for a binary answer, therefore the prompt might as well look the same in
both situations.

>From what I can tell the use of 'minibuffer-prompt' in minibuffer-less
situations has enough precedents (the "other clients" Martin mentions)
that the "minibuffer-" prefix might be considered a historical accident
by now…

(Perhaps those clients could be migrated to a new face,
e.g. 'message-prompt', which would inherit 'minibuffer-prompt' by
default?)


martin rudalics <rudalics@gmx.at> writes:

> 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.

Fair enough.  Should I raise the issue on emacs-devel, or create a new
bug report?  Just to make sure I am not omitting something, is this how
you would sum up the issue?

- In the context of bug#35564, I would like to add text properties to
  the y-or-n-p prompt (although I'm open to other, simpler solutions
  e.g. simply changing Dired's message).

- While this can be patched within y-or-n-p and we can call it a day,
  the minibuffer-prompt-face-adding code could be factored out of
  'read_minibuf'.

- This raises two questions:

    1. Do we actually want to use the 'minibuffer-prompt' face in this
       context, since the minibuffer is not involved?
       
    2. What do we do with other clients of 'minibuffer-prompt', which
       use the same (propertize prompt 'face 'minibuffer-prompt) idiom?


Thank you both for your thoughts on this.


[1] AFAICT, the commit that added this face (927be33, back when y-or-n-p
    was still a C function) does not say why this was thought to be a
    good idea.