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, 26 Dec 2020 10:30:47 -0800 (PST) Message-ID: References: <834kkcr1eo.fsf@gnu.org> <43b24209-fa65-0e26-7cbd-f99175a7ffd8@gmx.at> <87wnx7j5is.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19169"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, emacs-devel@gnu.org To: rms@gnu.org, Juri Linkov , rudalics@gmx.at Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 26 19:32:06 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 1ktEMI-0004sb-55 for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Dec 2020 19:32:06 +0100 Original-Received: from localhost ([::1]:49860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktEMH-0006tm-6j for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Dec 2020 13:32:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktELL-0006JO-PF for emacs-devel@gnu.org; Sat, 26 Dec 2020 13:31:08 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:40170) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktELF-0006Bd-Px; Sat, 26 Dec 2020 13:31:07 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BQIFSYi065143; Sat, 26 Dec 2020 18:30:55 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=iFeJDwLxMvOADb1jSJ/W3AyFJOfGHroi0jV6E9Aupp8=; b=qbUH7HQDcdf9XJPp8gLf0l2ne9h5/mUKDjY1btzh1vvfO4DmHuQQ6tNtqYvuW0TxAg+e +hMS4Pz8jQSyeSO8RF1oPFlvE623gkiv+Ywxv/PruwwpKK4BqBRX+3Gp/+GnyKVD45Vq rhejjiZoS64dxHCHJQJ7/oYZhDsR4yNWc0vmMFV3aTZ++zfg8YW+H0zFdlwJNv4+hACH 2QYb08oXW5zpcq0posKyslTOZ1MBGD4lpkYGwhoSVYsidBHk7LCweqq2jtBY7DR4cNTF ATazbvhOyTofBdalGrt0UINAHELuoFU23mJ637w4PP69Etui7B9Yqkm9gnnIBmjsWREg rQ== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 35nvkqgumu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 26 Dec 2020 18:30:55 +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 0BQIUmxu154885; Sat, 26 Dec 2020 18:30:55 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 35nt9r4q22-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 26 Dec 2020 18:30:55 +0000 Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0BQIUmsS019524; Sat, 26 Dec 2020 18:30:48 GMT In-Reply-To: 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=9846 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 phishscore=0 mlxscore=0 spamscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012260127 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9846 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 bulkscore=0 adultscore=0 priorityscore=1501 malwarescore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012260126 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.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, 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:261861 Archived-At: > > > Still I'd suggest to allow users to > > > separately choose for both, 'y-or-n-p' _and_ > > > 'yes-or-no-p' dialogues, whether they want Emacs > > > to handle them in a modal or non-modal way. >=20 > That would have these drawbacks > * It would mean extra complexity to debug, maintain, and document > * It would not directly provide the old behavior, only a basis for it. > People who want that would have to implement that. >=20 > Does anyone really WANT this generality, or is it generality for > generality's sake? >=20 > > Indeed. Here is a possible way to make the minibuffer modal: > > (defun minibuffer-lock () > > (when (active-minibuffer-window) > > (select-window (active-minibuffer-window)))) >=20 > I am not sure what behavior that would give. > But I think it is NOT the behavior that y-or-n-p used to > have, which was to reject unexpected answers. >=20 > What was the reason for implementing this change in the > single-character-answer commands? Who actually wanted > the change in behavior? And for what use cases? >=20 > If people really like the new behavior, I won't argue against it. > But maybe we should turn it off by default, like recursive minibuffers. FWIW: I opposed this new behavior. I think I was the only one who did, but that impression might be wrong. I opposed reading from the minibuffer for `y-or-n-p', in part because it can break existing UI dialogs (which may also involve the minibuffer at outer levels), but also in part because of the reasons you give (which are related). I opposed wholesale replacement of uses of `read-key' with use of the minibuffer. (Not that 100% wholesale replacement has occurred, but I sense that a general motivation in that direction has taken hold of the movers and shakers.) IIRC, this change was done in bug threads. I don't think there was discussion in emacs-devel. (Apology if I remember this wrong). In any case, as Eli is wont to say, "That ship sailed long ago." Alas. ___ Emacs 27 introduced several changes involving use of the minibuffer, which unfortunately have broken my personal use of Emacs (as well as some of my libraries, which are used by some other users). I use a standalone minibuffer frame, and I have lots of dialogs that let you interact in virtually any way with other buffers, etc. while a minibuffer interaction is in progress. E.g., for some commands that use the minibuffer, you can hit keys that initiate sub-dialogs, which can involve all kinds of things (and which typically don't involve recursive minibuffers). And the minibuffer, in my use, is very much an editing buffer, i.e., most editing keys/commands act normally there. I want it to continue to be general this way. I think some simplifying lockdowns of certain behavior have been clamped onto the minibuffer lately, based on (1) some assumptions that apply to presumed common interactions and expectations, and (2) attempts to "fix" some (relatively corner?) cases. That's an impression I have, and it's largely uninformed/ignorant, as I can't really make use of Emacs since release 27. So I don't use Emacs 27, and ditto for Emacs 28. I do sometimes submit bug reports for 27, as a result of looking into some questions from other users. But those are mostly doc-bug reports. Maybe, if I'm on the planet long enough and have enough patience and interest, I'll eventually get to the bottom of why I can't use Emacs 27+, what breaks what, and find workarounds. I'm not there now, and I don't foresee ever going/getting there, alas. I use Emacs 26.3, and perhaps always will. Just one (hardly typical) user.