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#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Date: Mon, 22 Mar 2021 23:06:23 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> 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="25093"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 23 00:10:51 2021 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 1lOThD-0006RF-0H for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Mar 2021 00:10:51 +0100 Original-Received: from localhost ([::1]:53472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOThC-0001Jv-24 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 19:10:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39176) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOTdW-0005Vh-Jx for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 19:07:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47556) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lOTdW-0003wJ-BJ for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 19:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lOTdW-0000Gd-6C for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 19:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Mar 2021 23:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47150 X-GNU-PR-Package: emacs Original-Received: via spool by 47150-submit@debbugs.gnu.org id=B47150.1616454398992 (code B ref 47150); Mon, 22 Mar 2021 23:07:02 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 23:06:38 +0000 Original-Received: from localhost ([127.0.0.1]:59102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOTd8-0000Fv-2P for submit@debbugs.gnu.org; Mon, 22 Mar 2021 19:06:38 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:56454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOTd5-0000Fh-Lf for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 19:06:36 -0400 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 12MN5j1c014692; Mon, 22 Mar 2021 23:06:25 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-2020-01-29; bh=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=; b=pVGICRBhRr6LALefniSbHxP488uJcYeFv4ignKNtGdQvUoK4qHZkfSiZ4sfjlF4IyybE CgDAHb4LjF1hZJQ3n+uf0tBMNtWLLP0ZxCZb7IkaCS8k9y/O0rsBDbUuJCHK9CpKzIWF zIxM44+oh8PJMtHuIVJ08MoYqQNQKZopFEwF552YSLrl9dq5Vwx2cq/xqyS3bwbwF+0j XP8lsuwAekQgArS3YOrkHaiM5qs/WtaQzqiCd1InivFk+Sf4qcVGTBRhQMb2AAtfL/kS LBC17f0jlkduzlXqWtqDeydmfVpccsXaHQqOMiglmUJYOlJjISnFpO785NilIFbjc7w5 cQ== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 37d90md37k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 23:06:25 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MN54Z7196254; Mon, 22 Mar 2021 23:06:25 GMT Original-Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by aserp3030.oracle.com with ESMTP id 37dtmnseuq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 23:06:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=amFjXF2P2ZLDcWi3EZ3svz1+NVnSatZk81Z7CNQMNlxl0cabepctCMmqiB4y1xg1TMj3rdO/XoeS8d1o91+MYlb0gdx+ZlzhBOCHiU77SUu2cFj5WUFhzJRSPwo3+QEkje7KsnHItrIRAU9w18GOOFa6G0t1A1GzMao1h5F4E15AOAbeJgyq05RWazx7NKMeYhe/yJgFiIEnY0ecfZxNSygbW5F/7FLmtBhvXVxCuIYrTY2iQCiTJj5HK6GjaQRtBnXRHen18yCUgrneTpVvWEksEfgFvZ8MMO4YH4UVxy0SymB+fh3Wuriay9DBQyPh7ZbENWliR3DDhq5bT27J+A== 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-SenderADCheck; bh=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=; b=FahqCc0KbdfkNkeyBsKvwt6QqNIBQyzI9G1fv26KdhIa4QOy1jMs6b6DhmwYWIV6vXUQHhnG8yWKpdgy3P8H3fD15m/pggSOYNHeNJGhs2oCsApUDERjuaOYTNIb0ogFx2nVVk6m90j/rKMaML9lwlKaOYDej+of9nDVfX2gjIUMFDPA/pHttShwslK1QrrE4P9gtY1gnIBS61K11KQ98Q0QndD0TsdfCEep/kzyvl0jYNZumd+U+qVY/rXeWIKumo7hGFeJnMMuaRq19vWebXtcbHNG0YnpdFIWh2YnMVL0XnUmG2Afpfu2x+tyI1VHrMPXRCX5ttZGySKIQFHCNw== 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=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=; b=Yd5+y1clGY4XHzRH9OvbxwWB78rdkf6H+smzeA5wDVQiQ9zV1JSc7JrCfVFk3loR4OSLMEqJ9Bz4Hz8D0IiJKcZgfAtSiMYtDc2bYeL+Z3haQ82VWn9ct1H+hqsJCtlkgKUDrQDLW46+E9fC0Q9C9FIFWjUWOe6+TenqU7su9js= Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SA2PR10MB4649.namprd10.prod.outlook.com (2603:10b6:806:119::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar 2021 23:06:23 +0000 Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021 23:06:23 +0000 Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXH2ZkGbJ696fBvEOoaQW9Kej3KKqQmMdg In-Reply-To: Accept-Language: en-US Content-Language: en-US authentication-results: muc.de; dkim=none (message not signed) header.d=none;muc.de; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7758aef-9275-4d64-bec6-08d8ed871cd0 x-ms-traffictypediagnostic: SA2PR10MB4649: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u1/pqbjoUibxpkiMxlZfmsN24S1h73OO0ht71PLW+nIZd4gpUP7f3lLpKB+FXpbbCrsPKHj7pbFEVlLENlbouZVGI6t0ugGHF0qjCqjRD3fSFL5vzCHbUpUJU/hb6LYq/nvElWVwkjZXtQEwhbOL9zwl++2wFjUAB8OxzwbIvJm7sITUQpSy0WYFde6gw4HkSYwBUjq9aFqKPkt+LKNcOUvtlKMBTz/meOZmyPQ0hdqvngtPVhdruvQtNJNMxrqz83LtXthrerGTrN96DkY3vas7ZhhASJIWLZFrEhjnswa/fcQFkS8TPRTDTiO0aZS0gMBR/I5U3kN2lifLix8V2Gy0uV8MFmboEEVK97PX6CopXJhgIcud0KNi6MW96RtpqvRVa8vKrzdtHzOTJH0icAvmuHsv0V5hUaz/cKL0d/eO8jiTU2h/ACdp0eHlyB6lBKuJbXZr5xKmfCSvtu05K5n+amRPzAh8rZsAxYWeq2oeAPPesMLGSXjmCOhBa94NvkMNlTHdi6jLKSyB+4H+SMtGaCQg2sXYVgjECoElSPXq0lDcjuOUDvpa1VxQLzyW1mfC+moU4lp2kKqqMqhJy/Gpswb40oywXXG3faZEOuPu/ZyfOEGRWPiPRpbGzEedTikB+rHNbRyjYWEp6ZLmHPJRqjmZsi0MS+6HoISjA7c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(39860400002)(136003)(366004)(71200400001)(76116006)(6506007)(6916009)(5660300002)(66476007)(86362001)(478600001)(66946007)(316002)(26005)(66446008)(66556008)(2906002)(186003)(64756008)(9686003)(7696005)(55016002)(33656002)(4326008)(38100700001)(8676002)(44832011)(83380400001)(8936002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9M4kU8wocriba3Ee4bfQrfN7uloBIzpckWCoHm6HU5GmQrJmOhKbdH2FUGfG3RUMPSiHHTtepKxyyNSDtIptNUJifBMbVYCXMSRpzzuVBECN+jVZrq7+E4vvMi9V8RXQT87gf1APYi7yIVxtZhe/IkssiboDBWAlunGDd4IQAG6PZXfJVGeIHMyPMIlonJRsg3g+F7FdBXfBwtHsYTFlWD+SWwixE04ICq8hsRyoDMCQpWQ9ZZRLtPxvVcjR6W4EExW8xD56GsW/mSJnrJqnvKSqfX/eB148e6KM3ILKpLkcZ9IBBGj4maaUyXJCQ+1YtW7NTnjeBkKUg6xmtdMwNUn3vZE5SkoLrYtCNN3r94TWIqmc2Zca0IcmpTy/i54WpTsssvYQ6CK9gXNZhJYqgM7Bc1qtqDrg7dTJ6G+JkCGng4Cy5VrCnpZ0XPjfw8ibkhtPhbZOw9E1Pw1Rdck+BMxImAhVeG9PxDfvWHUh8Dg6J84pjgmbVNYdlGbjHHh/YXWQqaI3037YzPqvzs4SKOEtsp8h7r7udGEmfuhxB5VVTwoSq73bFVqfVOF9JEijcuytsc7NYOT4Yrl0NitaOpxRpn+LhtyiknvCXQqx69pLANM1AFFRSobkg+e6v4ASIQcFPUYrxdODnmjEA8zyT7pKL5+2eZbMQMhjq1roU99q3bqvpg3sZr9fPlOWwWKL8LVC/87uoCkswJ+tL/FQF+XCOCH2CX1MsEqOzdL/KwTLk0xB4NGlV17wDSD2 rS3ZTk7D66aS4Gt8WMiAhjjZ+CPPoGQIhkTXDcbQq5MCj46KNat/UhLbPnGDPqBD6wA4L8VlxV4FJC30JQJk+72u6Mk4GmlbC7 x-ms-exchange-transport-forked: True X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7758aef-9275-4d64-bec6-08d8ed871cd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 23:06:23.1988 (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: k70f6E2RcWycb0sZI8XOZHJCdazpfs38U7pcMLezmvcCdrs+lXJYa7shZ/MiwdrXvUe/q2wy5Z9wbvmbosRtIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4649 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 phishscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220171 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220171 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:202875 Archived-At: > > > However, on being reused, these buffers remained in > > > minibuffer-inactive-mode rather than being restored to fundamental-mo= de. > > > This is silly, and "obviously" a bug. I fixed this bug by making an > > > active minibuffer always be in fundamental-mode. >=20 > > I don't see why it's "silly" or "'obviously' a bug", sorry. >=20 > It's silly, because the mode is called "...-inactive-..." and the > minibuffers were, at the time, active. It was obviously a bug, because > the major mode was different the first time the MB was used, from the > subsequent times. OK, silly mode name; agreed. But how was the major mode different? It remained `...inactive...', no? Yes, it became actually active, but the mode stayed `minibuffer-inactive-mode', right? Is there something more going on than a poorly named mode? > > Yeah, I see that the doc string for `minibuffer-inactive-mode' > > suggests that it's not used when the minibuffer is active. >=20 > > And that's effectively the case, though the mode name might > > not reflect it. There's _nothing to that mode_, apart from > > its keymap, and its keymap is not used when the minibuffer > > is active. So the mode is there in name only. >=20 > I haven't checked whether its mode hook gets run, but I think it would > (if anybody put any functions on it). OK. But does the mode ever get turned off, once it's turned on (at minibuffer creation presumably)? I didn't think so. My impression has been that the mode remains `minibuffer-inactive-mode'. I said that the behavior is "effectively" as if that mode isn't in effect - its doc description doesn't apply when the minibuffer is active. But the mode is still `minibuffer-inactive-mode' - or so I've thought. > > What if the name of that mode was just `minibuffer' > > or `foobar'? Would you think/feel the same way about > > needing to add another mode? Seriously - please think > > about this. >=20 > Well the behaviour of a minibuffer is so utterly different when it is > active, from when it is inactive (e.g., in a minibuffer-only frame) that > having them share a major mode doesn't seem right. But I take the point. It's a mode for the minibuffer; that's all. Yes, the behavior's different when it's inactive vs active - it's the key bindings. But the behavior's different when you use `completing-read' from when you use `read-string' or whatever - again, it's the key bindings (keymaps). Should we have a different major mode for each kind of active behavior - completing-read, read-file-name, read-buffer, read-number, read-expression,... All of those behaviors are different - different key binding. By your reasoning we should have different major modes for them, no? > > `minibuffer-inactive-mode' is, yes, a misnomer ... > > except that its (only?) purpose was to provide a keymap > > for use when the minibuffer is inactive. And the keymap > > name (with "inactive") comes free with the mode creation. >=20 > > If you really feel a need to clean something up here, > > consider changing that mode name (but aliasing the old > > one, for compatibility). To me, that would be the OCD > > end of story. >=20 > > > An active minibuffer doesn't use its own key map - > > > it uses the key map supplied to it by the calling function. >=20 > > Exactly. Exactly. Exactly. >=20 > > An active minibuffer doesn't have a separate mode from > > `minibuffer-inactive-mode' (a misnomer, when active). >=20 > > And functions dynamically provide different keymaps > > for different active-minibuffer contexts/uses. >=20 > > > This is how being in minibuffer-inactive-mode (which > > > does have its own key map) "worked" for so long. >=20 > > Yes. It just means that `minibuffer-inactive-mode' > > is a do-nothing when the minibuffer is active. >=20 > > But what's the point of providing a new mode for when > > it's active? What could/would/will anyone _do_ with > > such a mode? Keymaps are all that really matter here, > > and giving the new mode its own keymap would be useless. >=20 > > (At least it _should_ be useless. And it will be ... > > until someone decides that for "consistency" or > > "completeness" its keymap should really take effect.) >=20 > That's about the only thing I worry about (along with > the possibility of using a mode hook - but we have that > danger with minibuffer-inactive-mode-hook anyway, and > it doesn't appear to have caused trouble, as yet.) I really don't see the mode hook (on any such mode) being a problem in practice. Currently, the minibuffer is (I think) _always_ in `minibuffer-inactive-mode'. Its mode hook only ever kicks in when a minibuffer buffer is created. OK, that does happen occasionally, for recursive minibuffers. But I think worrying about its mode hook is fruitless and needless. > > Sounds like pilot error (misunderstanding) to me. Did > > OP demonstrate a real need to include a minibuffer mode > > in such minor-mode lists? IOW, where's the beef (bug)? >=20 > To quote the OP: >=20 > >>>> Packages depend on it [the major mode], to name a few: lispy, > >>>> smartparens, and telega. That doesn't answer the question about _need_. What's the real need for them to do so? That would make the bug understandable as a bug. > > Why? What's the need? Sorry, but I don't get it. It > > all sounds quite vague, as if someone thought that s?he > > really needed to specify a minibuffer mode in those > > minor-mode lists, and that need wasn't (isn't) real. >=20 > It's entirely credible that these packages use lists of major modes, and > that their use in an active minibuffer is appropriate. Sure, I get that (although it's abstract). But can't they just either special-case the minibuffer mode or explicitly include it in their lists: `minibuffer-inactive-mode'? Do we even know whether adding that major mode to their lists would solve their problem? > I'm not familiar with any of the three packages cited > by the OP, Nor am I. > but in previous discussions, we'd already been through > talking about using `minibufferp'. Dunno what that was about. See previous: the minibuffer has a major mode, `minibuffer-inactive-mode', doesn't it? Why is that harder to handle than some other major mode? > > > This isn't really the sort of bug that has recipes. > > That, right there, hints of a non-bug, I think. >=20 > That somebody is unable to configure a minor mode like > she used to do... Sorry, hold on. Like she used to do? So something was changed? Do you mean used to before Stefan gave the minibuffer the major mode `minibuffer-inactive-mode'? That was a while back. Did that cause a regression for the OP? > But maybe your idea of just renaming > minibuffer-inactive-mode (with an alias) and using it > for active MBs might be the best way to fix it. Seems straightforward to me, but I may well be missing something. As for "using it for active MBs" - there's nothing to change (IIUC): that misnamed mode is already used for active (and inactive) MBs (IIUC). It's just that the behavior of the minibuffer changes, depending on whether it's active and, if so, keymap is used for the reading. > > It sounds like a misunderstanding, to me. > On whose part? I was thinking OP. I was thinking that it should be sufficient to just include `minibuffer-inactive-mode' in their major-mode lists. But I admit to a poor understanding of the problem.