From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Date: Tue, 23 Mar 2021 13:05:29 +0000 Message-ID: References: <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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27409"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, acm@muc.de To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 23 14:06:10 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 1lOgjZ-0006zJ-MW for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Mar 2021 14:06:09 +0100 Original-Received: from localhost ([::1]:36982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOgjY-0005F8-EJ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Mar 2021 09:06:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51678) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOgjS-0005Ev-Jl for bug-gnu-emacs@gnu.org; Tue, 23 Mar 2021 09:06:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48290) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lOgjS-00020B-Cb for bug-gnu-emacs@gnu.org; Tue, 23 Mar 2021 09:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lOgjS-0004Jb-7l for bug-gnu-emacs@gnu.org; Tue, 23 Mar 2021 09:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Mar 2021 13:06: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.161650474016552 (code B ref 47150); Tue, 23 Mar 2021 13:06:02 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 23 Mar 2021 13:05:40 +0000 Original-Received: from localhost ([127.0.0.1]:59834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOgj5-0004It-Qg for submit@debbugs.gnu.org; Tue, 23 Mar 2021 09:05:40 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:54829 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lOgj3-0004Id-CN for 47150@debbugs.gnu.org; Tue, 23 Mar 2021 09:05:38 -0400 Original-Received: (qmail 86922 invoked by uid 3782); 23 Mar 2021 13:05:30 -0000 Original-Received: from acm.muc.de (p4fe159d5.dip0.t-ipconnect.de [79.225.89.213]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 23 Mar 2021 14:05:30 +0100 Original-Received: (qmail 6715 invoked by uid 1000); 23 Mar 2021 13:05:29 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:202900 Archived-At: Hello, Drew. Some confusion has arisen, which I'd like to try and clear up right at the top of this post. I have recently (in the last few months) changed the modes used by minibuffers. The OP for this bug has drawn attention to the difficulties these changes have caused. Before my changes: (i) An active minibuffer, the first time it was used, was in fundamental mode. In subsequent uses it was in minibuffer-inactive-mode. (ii) An inactive minibuffer was always in minibuffer-inactive-mode. After my changes: (iii) An active minibuffer is always in fundamental mode. (iv) An inactive minibuffer is always in minibuffer-inactive-mode. On Mon, Mar 22, 2021 at 23:06:23 +0000, Drew Adams wrote: [ .... ] > OK, silly mode name; agreed. > But how was the major mode different? > It remained `...inactive...', no? See (i) above. [ .... ] > Is there something more going on than a poorly > named mode? See (i): the fact that the first use of a minibuffer was in a different mode from subsequent uses. [ .... ] > > 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)? See (iii) and (iv) above. > I didn't think so. My impression has been that > the mode remains `minibuffer-inactive-mode'. This used to be the case, but is no longer so. [ .... ] > > > 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. > > 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). I think there's a difference here between "utterly different" and "slightly different". The question is whether the utterly-slightly distinction is sufficient to justify having two modes. You clearly think not. I'm, as yet, undecided. [ .... ] > > > 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. > > > (At least it _should_ be useless. And it will be ... > > > until someone decides that for "consistency" or > > > "completeness" its keymap should really take effect.) > > 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. Probably not [ .... ] > > > 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)? > > To quote the OP: > > >>>> 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. I honestly don't see the problem in accepting this bug as a real bug. After several exchanges (earlier on in the thread), the OP's current difficulties are clear, and they were caused by my recent changes in the minibuffer mode handling. [ .... ] > Do we even know whether adding that major mode to their > lists would solve their problem? I think so, yes. [ .... ] > > 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. There would be minor details to sort out, like does the renamed minibuffer-mode get rerun each time the minibuffer is used, and things like that. [ .... ] > > > 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. This was what was previously done, and because it no longer works is the cause of the bug report. > But I admit to a poor understanding of the problem. I'm not sure about that. ;-). Thanks indeed for the idea of just having a single minibuffer-mode, rather than two modes. -- Alan Mackenzie (Nuremberg, Germany).