unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
Cc: 35564@debbugs.gnu.org, Noam Postavsky <npostavs@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#35564: [PATCH v3] Tweak dired warning about "wildcard" characters
Date: Fri, 28 Jun 2019 11:43:55 -0700 (PDT)	[thread overview]
Message-ID: <581e7cf3-a99f-415d-a999-3b2f3f419c8f@default> (raw)
In-Reply-To: <87ef3dvbgq.fsf@gmail.com>

> > (And too long - "highlighted chars won't be substituted"
> > says the same thing as "the highlighted...".)
> 
> (Silly question: is it kosher to use contractions such as "won't" in
> user-facing text?  Or were you pointing out the superfluous "the" and/or
> suggesting "chars" rather than "characters"?)

Yes, and yes, and yes.

Well, for the first "yes": I can't vouch for what's
kosher.  But yes.

> >  "Should highlighted chars be substituted? "
> >
> > or
> >
> >  "Substitute highlighted occurrences of `*'? "
> 
> Mmm; currently this prompt is raised when the code detects that the
> characters will *not* be substituted; answering "yes" makes Dired go on
> with the command, answering "no" aborts.

Yes, I assumed, in saying that, that the sense of
the code would need to be reversed if the question
was put that way.  The question should be in a form
that's easiest for users to understand and not
misunderstand, if that's feasible in terms of code.

> If we phrased the question like you suggest, we should probably change
> the code to actually perform the substitutions should the user answer
> "yes".

Yes, that's what I meant.  But that wording was
just a casual suggestion, to get the point across.
Someone (e.g. you) might well come up with something
better.

> > 1. It's not clear to me what someone will understand
> >    by "substituted" here.  What would (otherwise) be
> >    substituted for what, where, and for what purpose?
> >    What substitution are we talking about, and how
> >    would a user be expected to know what we mean, here?
> 
> Right.  Not sure how to make things clearer without quoting
> dired-do-shell-command's documentation, which would make the prompt
> quite verbose.

Maybe someone else has a suggestion.  It's worth
working on, I think.

> > 2. Are there multiple different "characterS" involved,
> >    or is the confirmation about only _one_ character,
> >    in (possibly) multiple locations - occurrences of
> >    one char?
> 
> One character in (possibly) multiple locations.

That's what I thought.  Then don't say chars (plural).

> > 3. Is it the case that the new prompt does not, itself,
> >    show the character?  Do you have to look elsewhere
> >    to see which char or chars(?) are meant by the
> >    prompt?  Shouldn't the prompt itself show the char?
> 
> It does; the prompt shows the full command, and applies the warning face
> to the character(s).

Good.

> > A final comment, which I'm not sure is relevant:
> >
> > We should not, in any case, _rely_ on any
> > highlighting to get across meaning (semantics).
> > Highlighting should always be an extra - a
> > nice-to-have.  Some users will not see the
> > highlighting - it cannot be the only thing that
> > gets the intended meaning across.
> >
> > (Again, I'm not saying that we _are_ relying on
> > highlighting this way.  I just want to be sure
> > we're not.  We don't want to unnecessarily
> > introduce an accessibility problem.)
> 
> With the current patches, we absolutely totally completely _would_ rely
> on highlighting to get across semantics.  Thank you for spelling it out
> as an accessibility problem; that kind of confirms my nagging feeling
> that the highlighting method has an unfavorable benefit/cost ratio (IOW,
> it's cute, but it might make things worse for some users).

There is likely another way to make those occurrences
stand out (in addition to, not instead of, highlighting).
But I'm no expert on that.  Maybe Eli has a suggestion.

Emacs doesn't jump through zillions of hoops to try
maximize accessibility.  But it's good to keep it in
mind and, at least when other things are equal, to DTRT
in this regard.

> So to conclude, these are the paths forward that I see:
> 
> (0. Drop the issue and grit my teeth when the warning shows up.)
> 
> 1. find a simple rephrasing,
> 
> 2. keep trying to make a more elaborate prompt, only using some other
>    tricks to point out the characters.
> 
> Example of path 1:
> 
> > Confirm--do you mean to send `*' verbatim to the shell?

You can drop "Confirm--".  You could even drop
"do you mean to".  If a reply is required to the
question (e.g. it's `y-or-n-p') then users cannot
avoid it or miss it.

> (I don't like this one because it sounds like "do you want us to quote
> `*' to make sure the shell does not expand it?")
> 
> Example of path 2:
> 
> > Confirm--do you mean to send these characters as-is to the shell?
> > sed -e 's/foo?/foo!/' -e 's/bar?/bar!'
> >              ^                 ^
> 
> (I.e. using '^' to denote the non-isolated characters; not sure how
> clear it is that "these" refers to "the caracters underlined by a '^'")

Much better, IMO.  Again: drop "Confirm--do you
mean to", and use "these occurrences of `?'", not
"these characters".  There is only one char, in
perhaps multiple locations.

And I do think the char (`?' or whatever) should
be mentioned explicitly in the question, not just
have its occurrences indicated in the command to
be sent.

(Thanks for working on this.)





  reply	other threads:[~2019-06-28 18:43 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 [this message]
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
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=581e7cf3-a99f-415d-a999-3b2f3f419c8f@default \
    --to=drew.adams@oracle.com \
    --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).