[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35564: [PATCH v4] Tweak dired warning about "wildcard" characters
From: |
Kévin Le Gouguec |
Subject: |
bug#35564: [PATCH v4] Tweak dired warning about "wildcard" characters |
Date: |
Thu, 08 Aug 2019 12:40:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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.