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: Noam Postavsky
Subject: bug#35564: [PATCH v3] Tweak dired warning about "wildcard" characters
Date: Sat, 29 Jun 2019 09:48:25 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux)

Drew Adams <drew.adams@oracle.com> writes:

>> > 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.

>> 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.

Yes, we should definitely be careful not to make accessibility worse;
thank you for bringing this up Drew.

>> 1. find a simple rephrasing,
>> 
>> > Confirm--do you mean to send `*' verbatim to the shell?

>> (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?")

>> 2. keep trying to make a more elaborate prompt, only using some other
>>    tricks to point out the characters.
>> 
>> > 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 '^'")

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).

I like the use of "as-is to shell": short and clear.

> 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.

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)

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.

Attachment: 0003-Dedup-dired-aux-isolated-char-searching-Bug-35564.patch
Description: patch


reply via email to

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