bug#35564: [PATCH v4] Tweak dired warning about "wildcard" characters

[Kévin Le Gouguec]

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


Michael Heerdegen <michael_heerdegen@web.de> writes:

> Yeah, as mentioned, when coloring is possible, I would also just leave
> out the ^ underlining.

OK.  What exactly do we mean by "coloring is possible"?

1. "Does the warning face have a distinct foreground or background from
   the prompt face?"

2. "Are the colors distinguishable enough?"  (e.g. what
   shr-color-visible tries to guess IIUC)

3. Something else?

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.

I stayed away from this path because I wasn't convinced that we needed a
full-blown customization option for a supposedly rare branch in
dired-do-shell-command, and that we could live with the redundant
coloring plus underlining.

I'd be happy to make the prompt more succinct, as soon as I'm sure I
understand what we mean by "coloring is possible"!

>> > Warning: the shell may interpret 1 occurrence of `?' as wildcard:
>> > sed 's/?/!/'
>> >        ^
>> > Proceed anyway?
>
> I'm not happy with that either.  Look at it: there are quotes around the
> critical part, so the user might become crazy trying to find out why
> Emacs thinks the shell might interpret that as a wildcard.

Right.  Becoming crazy because Emacs sees phantom wildcards is the
reason why I started this bug report; I hoped that by saying "*may*
interpret", the user would understand that Emacs is basically saying
"this looks like a common footgun; I don't speak shell though so you
tell me".

> Maybe just telling what dired did not do would be better?  Like
> "N occurrences of X will not be replaced with the file/file list -
> proceed?

That would be the most correct description of the situation.  I didn't
go that way because the user might not be aware of this feature; I
failed to come up with a short prompt that would 1. explain the
substitution feature and 2. explain why Dired will not activate it here.

> Because, there are two things we mix up: (1) dired does not substitute
> with files, though the user might have wanted that, and (2) the char is
> send to the shell and is a wildcard there, so the result might also not
> be what the user intended.  Do we want to warn about (1) or (2)?  Both
> seems to be too much for one line of text.

Very much agreed.

> If we don't find a good wording maybe use something like
> `read-multiple-choice' or some other mechanism where the user is allowed
> to hit a help key (?, and that key should also be visible in the
> prompt).  We can leave an explanation that doesn't have to fit into one
> line in the help text.  I only mention `read-multiple-choice' because it
> provides all of that out of the box, of course there are alternative
> ways.

That sounds like a good compromise.  I'll see what I can come up with.