From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Confused by y-or-n-p Date: Wed, 23 Dec 2020 15:53:59 -0400 Message-ID: <87eejg1ep4.fsf@red-bean.com> References: <834kkcr1eo.fsf@gnu.org> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40250"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Richard Stallman , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 23 20:54:57 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ksADo-000ANg-TF for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Dec 2020 20:54:56 +0100 Original-Received: from localhost ([::1]:51136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksADn-0004TR-Uv for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Dec 2020 14:54:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksAD1-0003ei-AH for emacs-devel@gnu.org; Wed, 23 Dec 2020 14:54:07 -0500 Original-Received: from newsp.red-bean.com ([45.79.25.59]:35178 helo=sanpietro.red-bean.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksACz-0004iL-68; Wed, 23 Dec 2020 14:54:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:Reply-To:References:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=obn+b0zAFm4v/eWs6RT/bx6+r3Dbq8hfbTKIgkBdmFs=; t=1608753242; x=1609962842; b=EAgHnbM7MmbWUZrz/mxkMfBVvyEmK3P15DAPNEwjfqtIfxOyfexkY7s0f5TpUJr36ftih1OGk3 6/DBu9NrHmMCI2h17C7wB73DqnZLD2CnpMf70rWP7fzmjOahKUq01FK7b32nqD/nVY6xnS3rFHeOl YAj7lxwyRNEQu7M4GixUkQBnlK+p5WrV12YCiW+QBWkR+YvDuLEh36aV3AABWHm+KyhxZPNDJ18Y/ zbgDZ/hdOXjmuPol9jPwgh7U3fjUhY+dmBknc6TV7tgsPUMvZMXmxDUyZXyKiPB/4IGHbhorzGRvm GzMGSgHqTnL7T6RueCkJqrNAnqOq4R6fLwakA==; Original-Received: from host-24-89-198-178.public.eastlink.ca ([24.89.198.178]:36296 helo=klen) by sanpietro.red-bean.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ksACv-0008GV-7H; Wed, 23 Dec 2020 19:54:01 +0000 In-Reply-To: <834kkcr1eo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 23 Dec 2020 17:24:15 +0200") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261637 Archived-At: On 23 Dec 2020, Eli Zaretskii wrote: >The function y-or-n-p originally used to read only a small set of >character commands. In Emacs 27.1 we changed it to use >read-from-minibuffer, which means users now can easily switch out of >the minibuffer while the question they were asked is still not >answered. > >This could confuse some users, especially if they aren't used to >working with recursive minibuffers. Richard tells me it happened to >him several times. > >Would it make sense to add a user option to disallow switching from >the minibuffer in the middle of y-or-n-p? Then people who get >confused by this could set it to avoid the confusion. I'm surprised that the intersection of these two sets is non-empty: a) Users who would know enough to look for and set such an option. b) Users who would be confused by what happens after they switch away from a y-or-n-p minibuffer in mid-question. However, Richard is clearly in (a), and apparently he is in (b) as well. So there's an existence proof. I have no idea how many elements that set has, but if it has 1, it probably has more? So sure, given the recent behavior change in 27.1, having this option could be useful to them. (And, though I know some disagree, I don't think there's much cost to adding little options like this. Emacs already has a zillion of them, so targeted reading and discovery are the strategy everyone already uses to find them anyway, which means adding a new one does not increase the complexity of Emacs in a problematic way IMHO.) Best regards, -Karl