From: Michael Heerdegen <michael_heerdegen@web.de>
To: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
Cc: 35564@debbugs.gnu.org, monnier@iro.umontreal.ca, npostavs@gmail.com
Subject: bug#35564: [PATCH v4] Tweak dired warning about "wildcard" characters
Date: Fri, 02 Aug 2019 07:26:36 +0200 [thread overview]
Message-ID: <87sgqkjfxv.fsf@web.de> (raw)
In-Reply-To: <87r2688y1l.fsf@gmail.com> ("Kévin Le Gouguec"'s message of "Mon, 29 Jul 2019 21:01:58 +0200")
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.
next prev parent reply other threads:[~2019-08-02 5:26 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-04 18:01 bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters Kévin Le Gouguec
2019-05-05 8:44 ` martin rudalics
2019-05-06 19:40 ` Kévin Le Gouguec
2019-05-07 8:15 ` martin rudalics
2019-05-07 13:19 ` Drew Adams
2019-05-08 20:42 ` Kévin Le Gouguec
2019-05-08 22:39 ` Drew Adams
2019-05-09 8:13 ` martin rudalics
2019-05-09 14:17 ` Drew Adams
2019-05-09 17:51 ` martin rudalics
2019-05-09 20:04 ` Drew Adams
2019-06-09 11:08 ` bug#35564: [PATCH v2] Tweak dired " Kévin Le Gouguec
2019-06-12 12:23 ` Noam Postavsky
2019-06-12 14:29 ` Stefan Monnier
2019-06-13 6:19 ` Kévin Le Gouguec
2019-06-13 7:58 ` Stefan Monnier
2019-06-13 16:53 ` npostavs
2019-06-18 8:52 ` Kévin Le Gouguec
2019-06-19 0:12 ` Noam Postavsky
2019-06-26 6:16 ` bug#35564: [PATCH v3] " Kévin Le Gouguec
2019-06-26 13:27 ` Drew Adams
2019-06-27 5:58 ` Kévin Le Gouguec
2019-06-26 14:33 ` Stefan Monnier
2019-06-27 6:15 ` Kévin Le Gouguec
2019-06-27 23:31 ` Noam Postavsky
2019-06-28 6:15 ` Kévin Le Gouguec
2019-06-28 15:35 ` Drew Adams
2019-06-28 17:58 ` Kévin Le Gouguec
2019-06-28 18:43 ` Drew Adams
2019-06-29 13:48 ` Noam Postavsky
2019-06-29 14:30 ` Drew Adams
2019-06-29 14:13 ` Eli Zaretskii
2019-07-03 19:47 ` bug#35564: [PATCH v4] " Kévin Le Gouguec
2019-07-12 15:10 ` Kévin Le Gouguec
2019-07-27 11:20 ` Eli Zaretskii
2019-07-27 17:26 ` Kévin Le Gouguec
2019-07-27 22:22 ` Michael Heerdegen
2019-07-29 3:29 ` Michael Heerdegen
2019-07-29 18:11 ` Juri Linkov
2019-07-29 19:01 ` Kévin Le Gouguec
2019-08-02 5:26 ` Michael Heerdegen [this message]
2019-08-08 10:40 ` Kévin Le Gouguec
2019-08-08 21:06 ` Juri Linkov
2019-08-09 12:43 ` Kévin Le Gouguec
2019-08-09 18:03 ` Juri Linkov
2019-08-15 20:56 ` Juri Linkov
2019-08-19 4:55 ` Kévin Le Gouguec
2019-07-27 22:03 ` Basil L. Contovounesios
2019-07-27 23:32 ` Kévin Le Gouguec
2019-07-27 23:41 ` Basil L. Contovounesios
2019-10-10 18:45 ` bug#35564: [PATCH v5] " Kévin Le Gouguec
2019-10-22 15:10 ` Kévin Le Gouguec
2019-10-22 16:58 ` Michael Heerdegen
2019-10-22 21:32 ` Kévin Le Gouguec
2019-11-10 20:29 ` Juri Linkov
2019-11-14 7:02 ` Kévin Le Gouguec
2019-11-16 20:23 ` Juri Linkov
2019-10-22 20:43 ` Juri Linkov
2019-10-22 21:11 ` Kévin Le Gouguec
2019-10-27 21:40 ` Juri Linkov
2019-10-30 21:59 ` Juri Linkov
2019-11-04 6:36 ` Kévin Le Gouguec
2019-11-05 22:22 ` Juri Linkov
2019-11-07 22:17 ` Juri Linkov
2019-11-10 20:18 ` Juri Linkov
2019-12-18 7:11 ` Kévin Le Gouguec
2019-12-19 22:01 ` Juri Linkov
2019-12-20 8:53 ` Eli Zaretskii
2019-12-20 20:34 ` Kévin Le Gouguec
2019-12-21 7:08 ` Eli Zaretskii
2019-12-22 16:02 ` Kévin Le Gouguec
2019-12-20 20:43 ` Kévin Le Gouguec
2019-12-21 7:08 ` Eli Zaretskii
2020-09-20 11:42 ` Lars Ingebrigtsen
2020-09-20 12:04 ` Kévin Le Gouguec
2020-09-20 12:18 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sgqkjfxv.fsf@web.de \
--to=michael_heerdegen@web.de \
--cc=35564@debbugs.gnu.org \
--cc=kevin.legouguec@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=npostavs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).