GNU bug report logs -
#35564
27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters
Previous Next
Reported by: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Date: Sat, 4 May 2019 18:03:02 UTC
Severity: normal
Tags: fixed, moreinfo, patch
Merged with 28969
Found in version 27.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #20 received at 35564 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> 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 <at> 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.
This bug report was last modified 4 years and 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.