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 09:01:24 -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> 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 1516035637 30664 195.159.176.226 (15 Jan 2018 17:00:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 17:00:37 +0000 (UTC) Cc: contovob@tcd.ie, 30073@debbugs.gnu.org To: Juri Linkov , Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 15 18:00:33 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 1eb87R-0006zj-1W for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Jan 2018 18:00:21 +0100 Original-Received: from localhost ([::1]:47924 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eb89Q-0007uN-Q9 for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Jan 2018 12:02:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eb898-0007oN-1b for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2018 12:02:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eb894-0005wD-QR for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2018 12:02:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49814) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eb894-0005w1-KP for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2018 12:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eb894-0000f1-1p for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2018 12:02: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: Mon, 15 Jan 2018 17:02:01 +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.15160357021506 (code B ref 30073); Mon, 15 Jan 2018 17:02:01 +0000 Original-Received: (at 30073) by debbugs.gnu.org; 15 Jan 2018 17:01:42 +0000 Original-Received: from localhost ([127.0.0.1]:57711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eb88j-0000Nt-EX for submit@debbugs.gnu.org; Mon, 15 Jan 2018 12:01:41 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:50738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eb88g-0000GG-QZ for 30073@debbugs.gnu.org; Mon, 15 Jan 2018 12:01:39 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0FGvM7J013119; Mon, 15 Jan 2018 17:01:29 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=CuB7lcQuxpSjql6tYMcWmUwqLVATXj6x5g4hvRJB8S8=; b=lbmo/ZfzsJC28zCIXOpN7rCSzHC4HnuxcebFA7s+TWUqXfPRdQN99APu1VqTnKtOC6eP HbnkqWTXBGP8DCYp7PRG65tKqoCS4IGzz8JbLDHps1Fk+/OsPGMMzkpTt+/Bf/MvH7Qe f2k7Y84+Ko0iPFfoFR+5FwYy0NNX90E/SiEYNQ7/m1oGr+oyjwR9dcYwFmIwqHzHMwYM pMr2prfYT/icloZf0m50GA8XHymZ+Tkv3I9QmgexEJxDqvUb/2JFVo3ITrmJMZ2iCOVt H6o56PEugGmnzNK97tbdcJaGvojgGjj0QEQoSlOz+Jixh1YhZ+ZLltIm+44uCBxSxni+ sg== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2fgy9ng92t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Jan 2018 17:01:29 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0FH1SwG003431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 15 Jan 2018 17:01:28 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0FH1QbD032659; Mon, 15 Jan 2018 17:01:26 GMT In-Reply-To: <874lno10di.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-1801150240 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:142178 Archived-At: > Neither (fset 'yes-or-no-p 'y-or-n-p) nor > (advice-add 'yes-or-no-p :override #'y-or-n-p) > are good methods of customization, so dired-deletion-confirmer > and dired-recursive-deletion-confirmer are equally bad. >=20 > What I'm thinking about is introducing a boolean customizable variable > that would define whether abbreviated answers are preferred by the user. > Then a new minibuffer-reading function could accept a list of > abbreviations and map them to long full answers. >=20 > Something like =E2=80=98read-multiple-choice=E2=80=99 or =E2=80=98map-y-o= r-n-p=E2=80=99, but that > would allow either long or short answers depending on customization > like =E2=80=98rmail-confirm-expunge=E2=80=99, =E2=80=98url-confirmation-f= unc=E2=80=99, > =E2=80=98org-confirm-shell-link-function=E2=80=99, =E2=80=98org-confirm-e= lisp-link-function=E2=80=99, > or on its argument like =E2=80=98strong-query=E2=80=99 in =E2=80=98custom= -command-apply=E2=80=99. >=20 > WDYT? (I haven't been following this thread. Apologies if I misunderstand/misspeak.) First, why is this being discussed (only) in the context of Dired? Isn't this something to consider more generally? Do we all agree on the following points? 1. Users advising the yes/no confirmation-prompt functions is not a good solution to users wanting to sometimes (or always) use a different prompting approach from the one chosen by the author of the code that prompts. 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. 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'). IOW, it would be good for a user to be able to easily specify anytime, for a given prompting context, which prompting approach to use. An code author chooses which confirmation-prompting approach s?he thinks is most appropriate for most users in a given context. Typically, contexts where the wrong answer can have graver consequences get the `yes-or-no-p' approach. IIUC, this bug discussion is looking into the possibility of giving users a simple way to choose one or the other approach generally, i.e., for use everywhere, or at least everywhere within some overall context (e.g. Dired). Is that right? If so, that responds to #1 above, but not to #2 (or #3). Along those lines, instead of a Boolean value for a user option, to choose one or the other approach everywhere, perhaps an alist value would be good, with the alist entries (somehow) characterizing the prompting approach to use for different contexts (defined how?). Even so, though helpful, that would not really be a good response to #3 above. ______ I've proposed the following before, but I'll mention it again. It doesn't respond to #1 or #2, so it is likely complementary to what I think you're proposing, which is a user option to choose generally, as an alternative to advising. That is, it could be complementary. The first thing needed here is for confirmation-prompting functions to be able to (and preferably to do it) specify the current context in which they are called. That will give users a way to specify what they want for a particular such context. A start in that direction is to provide to the prompting function the name of the function that is calling it. No, that won't distinguish particular calls (occurrences). But it will be a good start. For example, if `y-or-n-p' is called from function `foo', and if the call records that fact, then a user can specify that all `y-or-n-p' calls from `foo' should be handled as if they were `yes-or-no-p' calls. This means adding an optional argument to `y-or-n-p' and `yes-or-no-p' (and other confirmation-prompting functions). If function `foo' wants to give a user control then it would use `(y-or-n-p "Do you agree? " 'foo)' instead of just `(y-or-n-p "Do you agree? ")'. Likewise, for `yes-or-no-p'. That's the only change needed, to give users control here. I've implemented this in library `yes-no.el'. I think it's a good start. Combined with a user option as discussed above, and overriding the option's more general behavior, it could offer quite a lot of user control unobtrusively and straightforwardly. `yes-no.el' works by allowing, besides the y/n and yes/no responses, a response that says "Switch to using the other prompting method from now on". It thus lets users change the prompting function interactively for the given calling function. In addition or alternatively, users can specify such preferences using a user option. Specifying behavior interactively updates the option value and saves it. IOW, interactive specification is an on-the-fly shortcut to using Customize. Rather than describe here just what it does and how, I invite you to have a look at the Commentary or code of the library, if you're interested. But the easiest way to see what it does is just to try it. https://www.emacswiki.org/emacs/download/yes-no.el I think it responds to the twin needs for (1) code author being able to judge which behavior is preferable for most users most of the time and (2) user being able to change the behavior anytime.