From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Newsgroups: gmane.emacs.bugs Subject: bug#35564: [PATCH v3] Tweak dired warning about "wildcard" characters Date: Fri, 28 Jun 2019 19:58:13 +0200 Message-ID: <87ef3dvbgq.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="249048"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 35564@debbugs.gnu.org, Noam Postavsky , Stefan Monnier To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 28 20:36:41 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 1hgvjj-0012aF-4H for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 20:36:39 +0200 Original-Received: from localhost ([::1]:35388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgvji-0002ff-3O for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 14:36:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59807) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgv9M-0002OA-0Z for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 13:59:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgv9K-0003KQ-3n for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 13:59:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57627) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgv9J-0003KF-WB for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 13:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hgv9J-0000Bm-Ts for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 13:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jun 2019 17:59:01 +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.1561744712655 (code B ref 35564); Fri, 28 Jun 2019 17:59:01 +0000 Original-Received: (at 35564) by debbugs.gnu.org; 28 Jun 2019 17:58:32 +0000 Original-Received: from localhost ([127.0.0.1]:42938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgv8p-0000AV-IS for submit@debbugs.gnu.org; Fri, 28 Jun 2019 13:58:32 -0400 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:40295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgv8l-0000AD-1u for 35564@debbugs.gnu.org; Fri, 28 Jun 2019 13:58:27 -0400 Original-Received: by mail-wr1-f52.google.com with SMTP id p11so7169447wre.7 for <35564@debbugs.gnu.org>; Fri, 28 Jun 2019 10:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=cUKy8CSmOqntMpgq7coaifqfpQgJj01Mk8TSfthjAe0=; b=udXtDXtSsxx9Jf5xV1GNWV3kGKp3P9amKU/jS6gtjKU77pQgekbObV0mUXu1lsEJ4b 9KhG27jVMmYU8CjA1URMMOd7dcZ2Mlt6Zgp/qhsIDMow4azLwsUYvhUL4Ks8Ike/Kz20 Mv827qVovodLBJAOPl0hdQsALpNnp+982dx1Ow+bRxppSynG2k9LU9uqtR/BHs9hB3od VzwsMi/0qiJZSPTWInB/0kis1mbc5VTjlSNuwueo3Ucjwu5sd/Kmfjr9y5gRaZXXAH7b sYSuRejhkWkDVzJ6bxQPkuSUjLxJbE6QqYzXEEPcnomtAU3NMmzpIWN+tmKyYRrNxMXX rJUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=cUKy8CSmOqntMpgq7coaifqfpQgJj01Mk8TSfthjAe0=; b=JHMG0/fYM7Fpfs5oxym66nc3NKiDmfjtdKsJCqK/9U9Y4mXVS4oN9aadaz+bn6M+gV Vcpk+kVcgWPW/zWaiUX5kt8/4UbXz13RK60x6mTjSNm0oP05OoeCVsy/wniNiymyXwEb /8y+fw7SeiZePJjsQz/dX8R73vpmh3uIraUXVg7xUUubHQe/tbjc5+J+RNbkb9Z0ewZ0 VuGzsYfAoJUwuq0872YtmMnaXJ/t1ZbRHCNwWpV3XGRwZa9dUGkbXyCDkKGbSRlmv8sY kWawB4y8fOKZ9guQob1bHUqHT9wbLd1G56gGZ2GgkcQc6Wv51S2hK1WV7cdEXeFT9dwx enbQ== X-Gm-Message-State: APjAAAXOU5FwJrK25VgnVBYDRbdzq6Oh7vQHnU02V05Z449i+4CQ0KFh GCih6PzQfgoFiIbneQiP5tE= X-Google-Smtp-Source: APXvYqxW+9DFN/JKDkuzrJMRpPJjfeHAbBWkF/KBPkEjiEQ/39dHe4OX38tgG7EzjozuEhd4J0GScw== X-Received: by 2002:adf:ed41:: with SMTP id u1mr8322716wro.162.1561744700957; Fri, 28 Jun 2019 10:58:20 -0700 (PDT) Original-Received: from nc10-laptop ([109.190.253.14]) by smtp.gmail.com with ESMTPSA id j189sm3204666wmb.48.2019.06.28.10.58.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 28 Jun 2019 10:58:19 -0700 (PDT) In-Reply-To: <32acf7a4-70d2-4c33-a3f5-18b082903d4a@default> (Drew Adams's message of "Fri, 28 Jun 2019 08:35:41 -0700 (PDT)") 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:161753 Archived-At: Drew Adams writes: > But the new question (and actually it's not even a > question - it should be, no?) seems even less clear > to me: A question would probably make the interaction more fluid, I agree. As fun as messing with text properties has been, I would still very much favour a simpler solution in the form of a better question (where "better" mostly means "does not talk about wildcards"). As I mentioned, the only reason I came up with these highlighting shenanigans is because I could not come up with a better phrasing. Point taken about the new phrasing possibly being less clear; I was aiming for some sort of "is the following statement correct? yes/no" interaction. > (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"?) > "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. If we phrased the question like you suggest, we should probably change the code to actually perform the substitutions should the user answer "yes". > 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. > 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. > 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). > 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). 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? (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 '^'")