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

[Michael Heerdegen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> > I dunno if the double emphasizing in the y-n-prompt (coloring +
> > additional underlining with "^") is a bit too much.
>
> The patch series started out with just the coloring, which we figured
> might have accessibility issues on its own (we can't assume that the
> user can distinguish colors); we added the '^' markers to alleviate
> this; then…

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

> (Assuming the first line you mention is "Confirm" and the second line is
> the command, which would make the '^' markers the third line; apologies
> if I misunderstood)

Yes, I suggested to combine Confirm... with the command in the first line.

> … I realized that when the user fails to answer 'y' or 'n', y-or-n-p
> prepends "Please answer y or n." to the prompt, i.e. this…
>
>     sed 's/?/!/'
>            ^
>
> … becomes this:
>
>     Please answer y or n.  sed 's/?/!/'
>            ^
>
> AFAICT, this means that we need a newline *before* the command (unless
> we add an optional RETRY-PROMPT argument to y-or-n-p or something).
>
> (I added comments to try to explain this in dired--no-subst-prompt; tell
> me if they need more work.)

Looks fine.

> And the irony is, I am still not 100% satisfied with it; I worry that
> the user will take "Send 1 occurrence of `*' as-is to shell?" to mean
> "Escape 1 occurrence of `*' so that the shell leaves it as-is?".
>
> Tell me if the shed is about to crumble under the weight of paint,

No, a valid concern, and it's good that you noticed.

> but if we are fine with so many lines, could we perhaps rephrase…
>
> > Confirm
> > sed 's/?/!/'
> >        ^
> > Send 1 occurrence of `?' as-is to shell?
>
> … to:
>
> > 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.  The
highlighting even more makes it look like there is something wrong with
the command.

Even "proceed anyway" as you chose makes it sound like this is an
exception/ something wrong although it is totally legitimate.

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?

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.

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.

Michael.