From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#35564: [PATCH v3] Tweak dired warning about "wildcard" characters Date: Fri, 28 Jun 2019 11:43:55 -0700 (PDT) Message-ID: <581e7cf3-a99f-415d-a999-3b2f3f419c8f@default> References: <87zho2cd4f.fsf@gmail.com> <87wohvf22u.fsf@gmail.com> <87h88cvpkj.fsf_-_@gmail.com> <87a7e27gh5.fsf@gmail.com> <8736jujkvj.fsf@gmail.com> <32acf7a4-70d2-4c33-a3f5-18b082903d4a@default> <87ef3dvbgq.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="15438"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35564@debbugs.gnu.org, Noam Postavsky , Stefan Monnier To: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 28 20:45:19 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hgvs7-0003rE-3H for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 20:45:19 +0200 Original-Received: from localhost ([::1]:35470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgvs5-0000JE-Vn for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 14:45:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39455) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgvrw-0000F1-IY for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 14:45:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgvru-0006VC-07 for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 14:45:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57666) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgvrq-0006Sp-Nt for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 14:45:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hgvrq-0003jD-Kd for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 14:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jun 2019 18:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35564 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35564-submit@debbugs.gnu.org id=B35564.156174744914228 (code B ref 35564); Fri, 28 Jun 2019 18:45:02 +0000 Original-Received: (at 35564) by debbugs.gnu.org; 28 Jun 2019 18:44:09 +0000 Original-Received: from localhost ([127.0.0.1]:42977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgvqy-0003hO-Hs for submit@debbugs.gnu.org; Fri, 28 Jun 2019 14:44:09 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:35932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgvqv-0003gj-P7 for 35564@debbugs.gnu.org; Fri, 28 Jun 2019 14:44:06 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5SIdgiM112809; Fri, 28 Jun 2019 18:43:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=NoEAplNqwPTtngcrHp8WIH5Wq8xPo3S/3HyaDVonLxk=; b=Zld5oaujWs+K9ngaM3wLybiklAw4jmKRJeoOvJjpUJ7Gy3LJQpU8hgWZRGTOpwEHQi6s P0r5/SdQxYMTSEQiLNQuBXEo6DBzSt003YW6p13yaEJDRRCJlkySqGe36ukGV21Ff7Ir owuZH5QZG/MJjdWeU8/eeFmoa7bVMi5fhp+BkLJpYuGRlsD+VwodMcqzbkeKeDWrQFKK V52xSqSbCltA8ock7Mdlm85YrxrJJnCNUNaRERAznCxEmAIQsZxfC61vTCpoFql3p9a3 Rp+BHtWnLW72rBtmgWxcF7wDynDq0WT6kQuU4TU6nNv49rrhXXg9vCAOIziqpXaV6w/c Uw== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 2t9brtq4g0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Jun 2019 18:43:59 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5SIhZsZ020745; Fri, 28 Jun 2019 18:43:58 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2tat7e3kdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Jun 2019 18:43:58 +0000 Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x5SIhurI031550; Fri, 28 Jun 2019 18:43:56 GMT In-Reply-To: <87ef3dvbgq.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4861.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9302 signatures=668688 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906280211 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9302 signatures=668688 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906280211 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:161755 Archived-At: > > (And too long - "highlighted chars won't be substituted" > > says the same thing as "the highlighted...".) >=20 > (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 `*'? " >=20 > 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? >=20 > 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? >=20 > 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? >=20 > 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.) >=20 > 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: >=20 > (0. Drop the issue and grit my teeth when the warning shows up.) >=20 > 1. find a simple rephrasing, >=20 > 2. keep trying to make a more elaborate prompt, only using some other > tricks to point out the characters. >=20 > Example of path 1: >=20 > > 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?") >=20 > Example of path 2: >=20 > > Confirm--do you mean to send these characters as-is to the shell? > > sed -e 's/foo?/foo!/' -e 's/bar?/bar!' > > ^ ^ >=20 > (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.)