From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#30073: 27.0.50; dired-do-delete ignores customization for short answers Date: Mon, 15 Jan 2018 16:48:15 -0800 (PST) Message-ID: References: <87bmi1cryh.fsf@mail.linkov.net> <87o9m1nlpl.fsf@gmail.com> <83po6g4cky.fsf@gnu.org> <87vag8f4da.fsf@mail.linkov.net> <83fu7b2yda.fsf@gnu.org> <87y3l1e68y.fsf@mail.linkov.net> <871sis66w1.fsf@gmail.com> <874lno10di.fsf@mail.linkov.net> <87d12aaedz.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1516063646 23649 195.159.176.226 (16 Jan 2018 00:47:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 16 Jan 2018 00:47:26 +0000 (UTC) Cc: contovob@tcd.ie, 30073@debbugs.gnu.org, Tino Calancha To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 16 01:47:21 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebFPA-0004xX-MX for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Jan 2018 01:47:08 +0100 Original-Received: from localhost ([::1]:48945 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebFRA-0004bd-Ji for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Jan 2018 19:49:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebFR3-0004bP-UQ for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2018 19:49:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ebFR0-0005TI-P0 for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2018 19:49:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50006) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ebFR0-0005St-Gj for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2018 19:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ebFR0-0000uL-2G for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2018 19:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Jan 2018 00:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30073 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 30073-submit@debbugs.gnu.org id=B30073.15160637153456 (code B ref 30073); Tue, 16 Jan 2018 00:49:02 +0000 Original-Received: (at 30073) by debbugs.gnu.org; 16 Jan 2018 00:48:35 +0000 Original-Received: from localhost ([127.0.0.1]:57903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebFQY-0000tg-U5 for submit@debbugs.gnu.org; Mon, 15 Jan 2018 19:48:35 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:36202) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebFQX-0000tQ-1V for 30073@debbugs.gnu.org; Mon, 15 Jan 2018 19:48:33 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0G0kvK6157819; Tue, 16 Jan 2018 00:48:17 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-2017-10-26; bh=0feGZYMSt7rfBwT4hFK10GRZMUSEsoDBSWWM0Q0sitg=; b=arq/FjoVknMH/m+iSv+zBxqJe54hqHm4qOPW0Fxtv9zjI0WEZmZxKIV563xD/I4PLaZx IEKYt5EbKDQK79K2Y7NOh34oJ7Odl7BCWGrQkF86ChwdgZ1bXebi5mVTbZLp5EW557T3 4TbvmKxeprt3qhPrQyL5+TeSKPbsM1EjcW0KAse78z0FeX76WeuywIbYGoNVDBGrRFpl x2oGqKEvNJ42r8GMykXBlW+XAqGctr8PivjSGkr7oEhh/DiS/RwMwJYEKEnfo6jfYIlS fylLnBgq6g5OIslWmuGyeoQ+cSm6IuHO2NBxhNsxcAHjvPnOj8MH9ojMCdFUyXSRgS54 Gw== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2fh701r0km-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 16 Jan 2018 00:48:17 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0G0mHbt029758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 16 Jan 2018 00:48:17 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0G0mGGG030666; Tue, 16 Jan 2018 00:48:16 GMT In-Reply-To: <87d12aaedz.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4627.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8775 signatures=668652 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-1711220000 definitions=main-1801160009 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: 208.118.235.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:142192 Archived-At: > I agree that advising the yes/no confirmation is not good > from a customization standpoint. >=20 >> 2. Choosing a single prompt approach (e.g. `y-or-n-p' or >> `yes-or-no-p') for all contexts might be appropriate for >> some users, but it is probably not a great idea in general. >=20 > Please see an optional argument =E2=80=98short=E2=80=99 that I added to m= y previous > patch. It will allow using short answers even when customizable > variable is nil where code authors deem appropriate. I saw it. That's not the problem to solve, IMO. It's not just about giving users a cleaner way to get `y-or-n-p' behavior globally, in place of advising `yes-or-no-p'. (I think/hope you agree with that much.) But it's also not about letting code authors decide which to use, even by overriding a user's preference. There's no need for that at all, AFAICS. Authors can already get "short" behavior anytime they want, and overriding a user setting that way would not be helpful. You're solving the wrong problem, I think. It's not only about moving from long to short. A user can want to go the other way too. And it's definitely not just about a systematic move in one direction or the other. Just as each _author_ can (and does) decide, for any given context, which kind of confirmation prompting to use, so can a _user_ make her own judgment about that. We're just not giving her a way to do that, today. We don't provide library authors with just a binary choice: ALL of your confirmation prompts must be long or ALL of them must be short. That would be silly. For the exact same reasons we should allow _users_ the same possibilities to judge and decide what behavior they want here and there. An author gets to decide that; so should users - a fortiori. We just need to provide an easy-to-use way to choose. That's what I've tried to do with `yes-no.el'. Other approaches to solving that problem are possible. But that's the problem to solve, IMO. Not just providing a substitute for advising - another way to give users an all-or-nothing choice. And not giving authors a way to override a user's choice. Users are different. They have different degrees of familiarity with Emacs and different degrees of confidence about the use of this or that part of Emacs. And those things can and do change over time. The first time you use an operation that deletes a file you might well want it to make you confirm slowly. After using it 1000 times you might want it to let you just hit `y'. Or not. >> 3. Even a given user might appreciate that a given prompting >> context asks them using the slow approach (`yes-or-no-p') >> at first, or most of the time, but she might sometimes, >> or even generally after some experience, prefer that that >> prompting context use a faster approach (e.g. `y-or-n-p'). >=20 > I'm not sure if we need more fine-grained customization. > If the user decides that a short answer is enough, enough is > enough. I disagree. It's not about just a general movement, everywhere from `yes-or-no-p' to `y-or-n-p'. It's about the particular user and the particular context. A given library might (from a given user's point of view) inappropriately use one or the other approach. It might use `yes-or-no-p' behavior everywhere, annoying many users. Or it might inappropriately use `y-or-n-p' behavior everywhere. There is nothing that guarantees a match between an author's idea of what is best overall and a user's idea of what is best for her in a given context at a given time. Did you try `yes-no.el'? The implementation and use are pretty simple - not a big deal.