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: Juri Linkov <juri <at> linkov.net>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 35564 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, npostavs <at> gmail.com
Subject: bug#35564: [PATCH v4] Tweak dired warning about "wildcard" characters
Date: Fri, 09 Aug 2019 00:06:33 +0300

> First, apologies for taking so long to respond - I was AFK last week.  I
> might not be very reactive these coming weeks either.

I use the substitution feature in dired-do-shell-command quite rarely,
but today I needed to use it, and it strikes as partly unusable
and confusing.  There are several problems:

1. Answering "no" cancels the command.  Instead of this,
it should proceed without substitution.  There is a special key
`C-g' to cancel the command.

2. The current question is too ambiguous:

  Confirm--do you mean to use ‘?’ as a wildcard? (y or n)

A wildcard can mean both dired substitution and shell substitution.
A better question should use the same terms as documented in the
docstring of `dired-do-shell-command', i.e. "marked files", "file list".
So a better question would be:

  Confirm--do you mean to substitute ‘?’ with marked files? (y or n)

Or something similar that makes clear that substitution applies
to dired files, not files matched by shell.

3. I still can't be sure if after asking these question, dired still
does the right thing.  I'd prefer to have an option to show the
final command before running it, exactly like `C-u M-x rgrep' does
with its `confirm' argument.  Yes, its command line is quite long,
but this is not a problem: wrapped minibuffer content is less
problematic than multi-line prompts.

> What bothers me is that even if we can assert #2, nothing guarantees
> that these colors will be distinguishable *to the user* (who may
> e.g. have some form of color blindness).  It would therefore be nice if
> this user could force Emacs to use ^ markers; I guess that would involve
> a new variable.

As was already discussed in this thread, using (:inherit '(warning underline))
will solve this problem and improve accessibility.  So there will be
no need in multi-line prompt when using underline face attribute.

Previous Next

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