From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Confused by y-or-n-p Date: Sat, 2 Jan 2021 09:06:55 -0800 (PST) Message-ID: References: <834kkcr1eo.fsf@gnu.org> <43b24209-fa65-0e26-7cbd-f99175a7ffd8@gmx.at> <87wnx7j5is.fsf@mail.linkov.net> <83im8qnyca.fsf@gnu.org> <83bleinmse.fsf@gnu.org> <56435592-d2d0-5fb6-977f-01e1931da835@gmx.at> <87k0t38g1z.fsf@mail.linkov.net> <83czyvkts6.fsf@gnu.org> <87bleetirr.fsf@mail.linkov.net> <87y2hhri3n.fsf@mail.linkov.net> <83pn2tkfg8.fsf@gnu.org> <871rf7ippu.fsf@mail.linkov.net> <83a6trg6mc.fsf@gnu.org> <87im8f951f.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9857"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, emacs-devel@gnu.org, rms@gnu.org, juri@linkov.net To: Lars Ingebrigtsen , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 02 18:08:43 2021 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 1kvkOR-0002VL-Jl for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jan 2021 18:08:43 +0100 Original-Received: from localhost ([::1]:53042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvkOQ-0001va-Js for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jan 2021 12:08:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvkN1-0001Q0-NF for emacs-devel@gnu.org; Sat, 02 Jan 2021 12:07:15 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:59070) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvkMy-0000TU-Fn; Sat, 02 Jan 2021 12:07:14 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 102H53YC170701; Sat, 2 Jan 2021 17:07:06 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-2020-01-29; bh=An2oIVVxcU1sNPZAZIVB2fNIHI2dRoDn22Wa2NLPDgQ=; b=SJr2VkgduI6reXmMJf4HLJzv/JP+34eee3KAwCeW8WZCx2QiV0hOOEG/Z6qafkUXjxpw bce9ERUVV47W3jJAEq7PoJZFTU8bNJ0p/n4FwHj/7kqIAQOKU3JPL42fPR4AJqtL+qhJ BxymrbQRJhUMh98Ra0CH+eYYpM/RvTKkkB+XChM2c5V9uxPClgs4q/chNtUN+Kvy0JaR /JOWIQ538et+2fep4KOrMfxyL15cCATlMnsz6ZBdVHxolDxAuaPhNxEhI/lZxQ+Fe1Mg dl5QzBhm9McqTvAs5U7Poy0tyVH+ZRNPaKFeKBMkCL0w2ViPbSlbZr082OIBKFAUgUR5 Mw== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 35tgskgqv4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 02 Jan 2021 17:07:04 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 102H5Bwo058052; Sat, 2 Jan 2021 17:07:03 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 35tfbmett5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 02 Jan 2021 17:07:03 +0000 Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 102H6uSa018448; Sat, 2 Jan 2021 17:06:56 GMT In-Reply-To: <87im8f951f.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5095.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9852 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxlogscore=871 mlxscore=0 suspectscore=0 bulkscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101020107 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9852 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 malwarescore=0 phishscore=0 impostorscore=0 bulkscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 adultscore=0 suspectscore=0 mlxlogscore=864 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101020107 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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:262329 Archived-At: > >> I think that y-or-n-p-use-read-key should default to t. > >> There is no hurry about making this change. > > > > Personally, I won't mind reversing the default, FWIW. >=20 > I think reversing the default would be less than optimal for two > reasons: 1) The new behaviour is in Emacs 27, and flopping back to the > Emacs 26 behaviour just sounds confusing See - that's the problem with saying that Emacs can just go ahead and change stuff, because we can always backtrack later. The cement overshoes start to harden immediately. People then make arguments like that one: it's already been released, so we shouldn't, or we can't, change it back. "Less than optimal." "That ship has already sailed." "The horse is already out of the barn." > I think Emacs (by default) should avoid being > "modal". Not being able to change buffers on > a y-or-n-p question makes it differ from how > Emacs behaves in almost all other > circumstances, which makes it inconsistent. Yes, "almost all other". Emacs has _always_ been inconsistent in that way - by design. Emacs has always been modal in contexts where it's important to require an immediate answer, e.g. a confirmation. That's always been a general exception. ___ But note the difference with `yes-or-no-p'. On the one hand, it requires more typing, inviting more attention and limiting accidental mischoice. On the other hand, it does _not_ prevent delaying a response and performing other actions. Consider changing to another buffer, opening another file,getting some help, etc., while confirmation awaits: (let ((enable-recursive-minibuffers t)) (yes-or-no-p "Are you sure? ")) ___ Beyond that, what you say there, which I agree with as a general rule, flies in the face of recent _big_ changes wrt preventing keeping the minibuffer active, changing focus somewhere else, doing other stuff, and coming back to the minibuffer (or never coming back: `C-g'). That kind of interaction is super-important to my own use of Emacs. Now it's been impeded. Imposing a predetermined rule about focusing, making hard-coded assumptions about minibuffer interaction, prevents users from changing focus the way they want, and so doing what they want. It was wrong to assume that minibuffer interaction always follows, and should follow, some single, rigid pattern. On l'a niqu=E9, le pauvre minibuffer. As a general rule, the minibuffer should not, in any way, be forced to be modal - wrt its focus or anything else. Not by default - modal behavior can be programmed for it, but that shouldn't be part of its general design.