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

Previous Next

Package: emacs;

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):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>, martin rudalics <rudalics <at> gmx.at>
Cc: 35564 <at> debbugs.gnu.org
Subject: Re: bug#35564: 27.0.50;
 [PATCH] Tweak dired-do-shell-command warning about "wildcard"
 characters
Date: Wed, 08 May 2019 22:42:45 +0200
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.