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.bugs Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Sun, 10 Jul 2022 16:13:03 +0000 Message-ID: References: <83zghm5evt.fsf@gnu.org> <5d86d890-9a2e-e4d6-13fb-da03285ea003@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39614"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "56305@debbugs.gnu.org" <56305@debbugs.gnu.org>, Eli Zaretskii , "monnier@iro.umontreal.ca" To: Alan Mackenzie , martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 10 18:14:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oAZZT-000A6t-0p for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Jul 2022 18:14:11 +0200 Original-Received: from localhost ([::1]:49904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oAZZR-0004ug-9a for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Jul 2022 12:14:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46486) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oAZZK-0004uQ-3C for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 12:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43831) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oAZZJ-0006bp-RO for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 12:14:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oAZZJ-0006Y0-L2 for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 12:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Jul 2022 16:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56305 X-GNU-PR-Package: emacs Original-Received: via spool by 56305-submit@debbugs.gnu.org id=B56305.165746959125100 (code B ref 56305); Sun, 10 Jul 2022 16:14:01 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 10 Jul 2022 16:13:11 +0000 Original-Received: from localhost ([127.0.0.1]:37728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oAZYV-0006Wm-3o for submit@debbugs.gnu.org; Sun, 10 Jul 2022 12:13:11 -0400 Original-Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:25840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oAZYS-0006WY-9W for 56305@debbugs.gnu.org; Sun, 10 Jul 2022 12:13:10 -0400 Original-Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26A98umr015585; Sun, 10 Jul 2022 16:13:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=fLzywf2y7g5ITrhrWAW8hnE5w/PO9OdFH/1kT4oT2xM=; b=m3AA7IvpSEv4l9ypKmNEiEu37wQX6Exqd/QFFc+ubvXkZL4VulsdloKekdFilOoKQkVv fePi9plSJVsdz4Uv75aimj+eL1YCQqa3y+rbPBolpYJFXgx8umSZS7TMisyugYexvsFN 69qj6ba1b9Jxx3jCI4RJCoHInX1oey8bE4XjrG+CTcgObvONMFP8CKsppu+Zoazv200r 5B7tvfBO7imd2Zp/cDhOaja3SOIzTxRpANLT6/NOXMeSiDCpoEN8fOZynB/rVRjXMMfe e9w3CUa+hhXa+eEi12Lyyr+s5KHex103T7P6912I5tDa08r0ZPNoTOHwbSV1q62PkR8c qg== Original-Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3h71rfspcc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 10 Jul 2022 16:13:06 +0000 Original-Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 26AGBRYv029069; Sun, 10 Jul 2022 16:13:05 GMT Original-Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2168.outbound.protection.outlook.com [104.47.59.168]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com with ESMTP id 3h7041hruv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 10 Jul 2022 16:13:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bO9mbcjZYKMfe90Th1PNzPay3UU37x7xQgxDMABoIbFzOHwozpzOqnTsTkAAp8jXt7TUDb6zU6+5t0gsFVTCl8ynt8iVM+Y6Jzj09BUCLJ9Sm7KlwgHx4/q8g4A5/No0wtTIfhO0yCTLsTcrPSCZfOjTgJtUcN315ThHZ2BCMAPq3ZekavlV+Lz6Twm07eF/hr5CCbBMv7K7zu7DBJ9kuVch5+1XxMig80yd+oBzI3hL+nBfJ/+KjdzeJMTpZIb9zSr99jf2MtpB6wBEAVNsMmdHkW8b9O95plLHgTQeVZ0Sh2hVfVa4LAD+ghIoINsA9YidNKOKq5WhfB5c5osC2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fLzywf2y7g5ITrhrWAW8hnE5w/PO9OdFH/1kT4oT2xM=; b=GR2geG7UwnHk61IM2wtMUNBkZlhD33xX1r4OMZI0+f0Scvz+cvCgowNs8KQ1kL4b/VlzpR56/VPZZlErexnjn/c7TeqAeSSwRgpANcQTa9E/QgiV/nsJQ1LeFI61N19ajB88tpGP3v0n4r81nRsryclxbGtkPUcv1oqrYN5iBB1OotzcpBOFWYncWPHlp1Bl3lZpb3+6p9vypWw3wvHLvC9gJr37W2Avs/fE/MwXZF0T3/304UufvdEkCOtxu0pbZcZ8NV9U0fEag1zRIjeBBcBeXiynJJ1aR2MEPxJPsr1tO7rrsgQM4sZ/MhkV8O+jiGHh8E/bpfgy4LzjG21eWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fLzywf2y7g5ITrhrWAW8hnE5w/PO9OdFH/1kT4oT2xM=; b=y7C43SljTZZAWQQzjWCrvcEDYb76+YjMw9TXBYa9fNjcobzFFv9Kr3qnPDVWZ7x5P81HtYuk74W3+mfLmOYij1gXTSzUBz/j4w0zvYqAn8ReIQg9RlYnPZxUmgX2iwjNstpWj42qIHo2ueMEJl65aUZELtTTZVQRGqav3lgXMhU= Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by PH0PR10MB5436.namprd10.prod.outlook.com (2603:10b6:510:e2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.16; Sun, 10 Jul 2022 16:13:03 +0000 Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::581b:ae2f:16b9:80fb]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::581b:ae2f:16b9:80fb%7]) with mapi id 15.20.5417.026; Sun, 10 Jul 2022 16:13:03 +0000 Thread-Topic: [External] : bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Thread-Index: AQHYlFEg9EfqKmuLnUWv2Ib3TWRD3a13rv5A In-Reply-To: Accept-Language: en-US Content-Language: en-US x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dbdd06ae-848e-4911-8c0e-08da628f1144 x-ms-traffictypediagnostic: PH0PR10MB5436:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bnUK6iasFoTcqjxX6i+fmpwEX8OmqekZynwj1Lp+2cTWwVoVG2xcUnZ4SLk9Ayah46XrsOh72dwVhtam3s6VuuKN9NxYMSObYHIZGUGjnj7EDRoitiCNxPBC5T3p44sJwUNrFStQCNM+zuneYcxHcnGb+t+Lp5lb4eRTWapmszyjIBEcvENdvGbQi+NH+cfMlRA5lVC22RKyu8Hf/wE94LrmDnV2RJsaECy7YlfYWZDKK0FWyL64OefaZQ2Mv4lRvba3ScQ1oFRB+gQaKsK9JdKi8qNtusjkXtMSTtqLKepngoM5XJcy1/gKgfQWwgcxeeojL6mof0GrEMHccC5jhYjVzTHhw3lubUIcpvf93xcUMmCY7l/biVSDCYT2Qv4J/ib4P9EYjx2/jTi2R+7BCY2yQjaRVLZ9btUQdNwYZFRB3N3YiXCu6bHlT1bwKFobSMfp+xoKzKJBZNfBjX/GuRORKLBXo9VhQFHO841KlGH6J7NqyIzZGLDqW1z5xNXiKc0o4vSOZ48OoXvwFZlp1gQY+NpY8VcQgmljMEaDGvOqOdHravyWomI5DUL3OpjejwOqGC0ENKX7uspRnaaR9aJg3uiTszAaKz8nhrDr7IZuDsBFT9aAwDd0jhlfnldt/FI2i8rIt4dEg+SIJRFjhR7R2b0Uqjw8KR7I1dAWk35r3kojJrzJ8/5paq3Pyz9KyNmxuva10j+cF+YbVTfwT61fBqYzdIHGt6KWbPWtPCifmkbjd8dLaykoIOn1A 8l9qCvi9OM6IlqhpV8g7DNDuKIix5CnESxvhTMxVoAjtsZwB05aISr02mWs8NvFQ0SZ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(366004)(396003)(136003)(376002)(346002)(39860400002)(38070700005)(122000001)(38100700002)(186003)(5660300002)(4326008)(8936002)(52536014)(44832011)(76116006)(64756008)(66476007)(66556008)(8676002)(66946007)(66446008)(2906002)(55016003)(41300700001)(9686003)(6506007)(26005)(110136005)(478600001)(316002)(54906003)(7696005)(71200400001)(33656002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: qHL2nxFpwqgn8VIGwr5Y7ixJs6JKWQ++TUS9uPVcrpeFth9/0/f50nUCg94Ce97HZUGQJR3FOoDWY5I5gQQRcMW3TN1850AyDPoaC8S3HnKSQVtr7POoTjca5adbAtU29sHncUOLJx6dhaatgXyoJ4iM+OkTkJmQIv23n+IaLVeK+D0hR11+o2lYpg61eGpRTksrgEUKEDSy50ZA7M58lrFuzpd4mnxsK6nwbJJIvHe5bJnNC+ynrSImdULeA5fq/eZfE46NsofBkLffUWifA4BKMW09FTonSpiBTDER+VNjp1Faa0Wf3W8dsPxJykRScp8zNqo6mhpdj1/InKviuHTXeuKxWcq3u/Zzjmfh5zo9LA8I34UD/5AwKT7xjI3IUz2QnmDOqQQpTh+vovIe51ypFuOa/F/UFXt8BJMi0FD5Kx6b6edZFr3f2E4ZkbfAtZ19voFnkJSM12FxG5+8ScRB/hTRgHIK2fhnqURvpdFbvpozwao0SQg9qxxbz1hyTjKw945XqXodHyZTz0LUG3a8k394FUG+m+TqmNoM1p7uEg0TBqW+6O90MTBnwQvBy5Pr5vz3EWqMMCtWvUKUnqJlp4LnlBVqzwsaOftqtndtyXKKa8EllqzQrl8/AhxDeD/CcIqGefmMGNDJZ2Lnelfm82C+K36qBewlDWW8F4XsvbejDU/oGJjPpP0qiBilxLVUUeC1Qu450MeZ17wTXmkqFvTUyRu3QftO9t63ry2PpVURs2cB3LzFvC hnilAENP5a9+kbpbOdYGLQEhrpXkLE3wXv2+atUvOSLuh3WZ7V4JNTKP6gc7OT35T638KMHFZwZ3PHuhk9g0IvDxc/p2wgBTOt X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dbdd06ae-848e-4911-8c0e-08da628f1144 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2022 16:13:03.5428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HbGpKqHfBT5K+oMs1p/ErsHgM8CUAYPRlMQKPz3oSezsUXsNYo+NtTSCRvDLzJMGGFUJEdP/q6s/RBzbctldBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB5436 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-10_16:2022-07-08, 2022-07-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207100073 X-Proofpoint-GUID: 1TbUtCs58bVv2Bar7LMXSwXoTyB7on9w X-Proofpoint-ORIG-GUID: 1TbUtCs58bVv2Bar7LMXSwXoTyB7on9w X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236587 Archived-At: > I think that might be over-stating things. > Most of the time, users are just going to be > typing "yes" or "no" here. [Big caveat: I'm not following this thread.] FTR/FWIW - I expect that there's lots in here that I don't agree with. But there's also lots that's happened over the last few releases that I don't agree with, wrt Emacs grabbing or changing the focus (frame) from what my code or user actions have decided. I tend to think that such changes have been essentially gratuitous (unconsciously so), even if someone thought they were called for to fix this or that reported problem. Fixing one user problem can easily mess up other things. And fiddling with frame focus is a particularly sensitive kind of fiddling - including because different platforms can do things differently. ____ I'll just say this wrt `yes-or-no-p' - at least wrt how it _used_ to behave. `yes-or-no-p' is just a function that reads minibuffer input. As far as that reading's concerned, it's "modal" in this sense _only_: you can't end the reading of minibuffer input without hitting `C-g' or `C-]' or similar, or else entering `yes' or `no'. That's it - nothing more modal than that. There's _nothing_ that prevents a user (and code invoked by the user hitting a key etc.) from changing the focus to another window or frame, and carrying out any number of actions there. Even multiple frames, successively. (Not to mention recursive minibuffers.) There should be _ZERO_ expectation by Emacs that focus should remain with the minibuffer during `yes-or-no-p', any more than during any other minibuffer interaction. [`y-or-n-p' _has_ been thoroughly modal in the past. It expressly did _not_ use the minibuffer. But now it reads input from the minibuffer...] Users and code need to be in control, able to change focus away from the minibuffer and back to it. Emacs really shouldn't get in the way. Once Someone(TM) gets the idea that focus needs to be kept in the minibuffer, we're headed down the road to knee-capping code and user - crippling the minibuffer. And that, no doubt from good intentions. Good intentions, but maybe some ignorance of minibuffer possibilities. The minibuffer is just a buffer - there's _NO_ prescribed, ineluctable, "consistent", simple behavior that can be counted on. And there should be none. That's a GOOD THING. At least that was the case before any sanitizing mission started blasting away. More and more, it seems, if you write code that takes advantage of how Emacs behaves you'll lose, because Someone will climb under the pavement and make a fundamental change that "fixes" some perceived problem, upsetting the apple cart above. ____ Here's the general problem I see wrt someone trying to "regularize", make "consistent", "simplify" - or whatever - minibuffer interaction, including focus: You'll undoubtedly screw things up by making simplistic assumptions - either about user or programmatic behavior or about state at some point. Sorry to say that (really), but that's my conclusion. I know that people mean well, but that's what happens, IMO. Why do I say that? Because I think that's what's happened, to break my code. Starting with Emacs 26 (I think Stefan has pointed to this) - and definitely with Emacs 27, Emacs has apparently tried to get too smart about such focus things - making more assumptions about what users and code will or should do. The result: _Emacs changes the focus when it shouldn't_. I can't be more precise than that. I've given up. I don't have the time to chase it. I use only Emacs 26 and earlier now. My code, including as a result of user actions, _explicitly_ uses things such as `select-frame-set-input-focus'. IOW, my code, and users, control the UI, including focus. Alas, that careful control has been broken by Emacs. No doubt Someone thought he was doing Emacs and its users a favor "cleaning" things up and making things more "consistent". Nothing but good intentions, no doubt. No carelessness, I assume. Instead of giving code & users _more_ control, to handle frame focus as they see fit, Emacs has itself apparently tried to take control. Too smart for its own britches. The fault is in accidental hubris that can creep in by not appreciating that Emacs allows for umpteen _zillion_ different states and interactions. It's all too easy to think that every user, use, use case, and setup (configuration), and all Emacs code, are more or less similar to your own use, setup, code etc. Someone makes a "consistency/cleanup" change, tries it out with a few (even many) setups, and considers it a job well done. Shiny. Maybe someone else reports, in vague terms, that Emacs now breaks things. Without a clear, simple recipe to show that, Emacs just goes ahead with the new "improvement". And on it goes. What was stable for many years becomes something different, less flexible, etc. The minibuffer, in particular, is just a buffer. And it can be in its own frame. Users and code can switch focus to & from that frame, including during minibuffer interaction. And other frames (e.g. a dedicated *Completions* frame) can have their focus redirected to the minibuffer frame. And such redirection doesn't prevent code or users from switching the focus to such a frame, and back again. In short, it should be possible to do pretty much _anything_ while the minibuffer is active. And that - especially - includes changing the input focus among different frames.