From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: yes-or-no-p prompt conditionally broken in master? Date: Sat, 05 Sep 2015 14:02:18 +0900 Message-ID: <87pp1x31d1.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83k2s7a247.fsf@gnu.org> <55E88336.5060703@yandex.ru> <83h9nb9z5l.fsf@gnu.org> <55E8879B.9050107@yandex.ru> <83fv2v9y9z.fsf@gnu.org> <57355235-9af7-49fb-81b5-93182cfc9d49@default> <83a8t39x3t.fsf@gnu.org> <83zj128slp.fsf@gnu.org> <87k2s6o7qh.fsf@igel.home> <87si6umqbs.fsf@mbork.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1441429370 16840 80.91.229.3 (5 Sep 2015 05:02:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Sep 2015 05:02:50 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Marcin Borkowski Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 05 07:02:40 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZY5cc-0008Gg-1l for ged-emacs-devel@m.gmane.org; Sat, 05 Sep 2015 07:02:38 +0200 Original-Received: from localhost ([::1]:37590 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY5cc-00020b-Cc for ged-emacs-devel@m.gmane.org; Sat, 05 Sep 2015 01:02:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY5cR-000206-0p for emacs-devel@gnu.org; Sat, 05 Sep 2015 01:02:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZY5cQ-0000bC-4E for emacs-devel@gnu.org; Sat, 05 Sep 2015 01:02:26 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:44168) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZY5cM-0000YV-8j; Sat, 05 Sep 2015 01:02:22 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id CB16B1C3986; Sat, 5 Sep 2015 14:02:18 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A5AED11EF83; Sat, 5 Sep 2015 14:02:18 +0900 (JST) In-Reply-To: <87si6umqbs.fsf@mbork.pl> X-Mailer: VM undefined under 21.5 (beta34) "kale" ffb5abc8dc4e XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189625 Archived-At: Marcin Borkowski writes: > On 2015-09-04, at 11:26, Andreas Schwab wrote: > > Eli Zaretskii writes: > > > >> Any objections to removing yes-or-no-p (with a defalias for backward > >> compatibility, of course) and making y-or-n-p serve both duties, > >> controlled by some defcustom? > > > > That doesn't make sense. They implement different intented > > meaning. The API would need an argument to control it, and in that sense Eli's proposal is incomplete. But it makes sense. > +1. They serve different purposes, and they are both needed. Both semantics are useful, but they serve the same basic purpose. There's no good reason for having separate APIs, and it's arguable that maintaining parallel syntax is sufficient reason for unifying as a single API, given some core developers' aversion to making promises about consistency of API. If I were a "I never saw a behavior that I wouldn't make optional" fanatic, I'd go on to propose an elaborate API and UI, where the main function would be (defun user-confirmation (prompt oracle) ; not optional!! "The docstring is left as an exercise for the reader." (if (functionp oracle) (funcall oracle prompt) t)) ; #### too fragile in the face of typos? And the options would be stuff like: (defcustom user-confirmation-fatfinger-fandango 'y-or-n-p) (defcustom user-confirmation-irreversible-change 'yes-or-no-p) (defcustom user-confirmation-truly-timid-user "don't bother me!") (defcustom user-confirmation-authenticate 'reauthenticate-user) But I really don't see the need for a unification or generalization. The two levels are enough. Security-relevant cases will probably have their own mechanisms anyway, and nobody would be very likely to want to set truly-timid-user to anything other than "don't bug me". Nor can I see any reason why the syntax would need to diverge. Just promise that (defalias 'yes-or-no-p 'y-or-n-p) will work forever. If necessary to change one or the other's signature, add dummy arguments to the function whose implementation doesn't change.