bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#35564: [PATCH v3] Tweak dired warning about "wildcard" characters
Date: Sat, 29 Jun 2019 07:30:01 -0700 (PDT)

> >> > Confirm--do you mean to send these characters as-is to the shell?
> >> > sed -e 's/foo?/foo!/' -e 's/bar?/bar!'
> >> >              ^                 ^
> 
> I don't know about the '^' trick, if the minibuffer window is narrow
> enough to cause line wrapping the result won't be very readable.  And I
> doubt a screen reader would handle this kind of thing any better than
> highlighting (someone please correct me if I'm wrong about that).

Another possibility I almost mentioned is to
use, by default, a face that uses `:box' or
`:overline', or some such properties to make
the char occurrences stand out without relying
on color.  That might at least help with some
who have difficulty distinguishing color, but
it's not an ideal solution either.

I don't think we should try to jump through
too many hoops about this.  The main thing,
I think, is to put the char itself in the
sentence preceding the quoted command text.

The use of `^' is not too bad, I think, even
given the problems you mention.  If the char
occurrences that are problematic are not
obvious then a user can cancel the command
and check `*Messages*' for the full feedback.

> Agreed on both these points.  Updated patch is below, it produces
> prompts like these (still using highlighting):
> 
>     echo foo*
>     Send 1 occurence of ‘*’ as-is to shell? (y or n)
> 
>     echo foo* bar* *
>     Send 2 occurences of ‘*’ as-is to shell? (y or n)

Good.  But "occurrences", not "occurences".

> The last case (where there are both as-is and substituted "*") isn't so
> great without highlighting (you have to count the "*"s and work out if
> something unexpected is happening), but I think it's at least not worse
> than the current situation.

I vote for also adding the ^ indications underneath.

If you think that is too often too problematic then
maybe do something like one of these:

1. Give users a way to opt out or to remove that on
   demand.

2. Automatically remove it, based on window width,
   whether there are multiple lines, or whatever.
   But this should be controllable by a user (e.g.
   an option).

Agreed about use of screenreaders.  Users should
be able to turn off the ^ indicators.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]