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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 35564 <at> debbugs.gnu.org
Subject: bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters
Date: Tue, 7 May 2019 10:15:42 +0200

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.