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: Mon, 22 Mar 2021 21:57:37 +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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33179"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 22 22:59:12 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 1lOSZs-0008Vo-Ow for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 22:59:12 +0100 Original-Received: from localhost ([::1]:35122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOSZr-0005yq-NL for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 17:59:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53100) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOSYk-00059A-CR for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 17:58:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47500) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lOSYk-000714-2v for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 17:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lOSYk-0004oP-0r for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 17:58: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: Mon, 22 Mar 2021 21:58:01 +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.161645026718479 (code B ref 47150); Mon, 22 Mar 2021 21:58:01 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 21:57:47 +0000 Original-Received: from localhost ([127.0.0.1]:59046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOSYV-0004ny-E6 for submit@debbugs.gnu.org; Mon, 22 Mar 2021 17:57:47 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:32027 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lOSYT-0004nk-AV for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 17:57:46 -0400 Original-Received: (qmail 62438 invoked by uid 3782); 22 Mar 2021 21:57:38 -0000 Original-Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 22 Mar 2021 22:57:38 +0100 Original-Received: (qmail 9173 invoked by uid 1000); 22 Mar 2021 21:57:37 -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:202872 Archived-At: Hello, Drew. On Mon, Mar 22, 2021 at 17:09:32 +0000, Drew Adams wrote: > > Things are already broken, slightly. > I don't see that you say how things are (even slightly) broken. I think I meant that with regard to the philosophy "if it isn't broken, don't fix it", in that I had already fixed it, so a further fix in the vicinity wouldn't do any further damage. > > In my recent enhancements to the minibuffer handling, I noticed that > > minibuffers (the actual buffers) began life in fundamental-mode, got > > used, then on termination were put into minibuffer-inactive-mode. > > However, on being reused, these buffers remained in > > minibuffer-inactive-mode rather than being restored to fundamental-mode. > > This is silly, and "obviously" a bug. I fixed this bug by making an > > active minibuffer always be in fundamental-mode. > I don't see why it's "silly" or "'obviously' a bug", sorry. 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. > Yeah, I see that the doc string for `minibuffer-inactive-mode' > suggests that it's not used when the minibuffer is active. > 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. I haven't checked whether its mode hook gets run, but I think it would (if anybody put any functions on it). > That's why I expect that your change will have no real > effect. But I'm wary of it - let sleeping dogs lie. And > if it does, in fact, have no real effect, then why make > your change? Because of the negative effect reported by Sheng Yang, the OP. > This seems like a solution in search of a problem. > 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. > `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. > 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. > > An active minibuffer doesn't use its own key map - > > it uses the key map supplied to it by the calling function. > Exactly. Exactly. Exactly. > An active minibuffer doesn't have a separate mode from > `minibuffer-inactive-mode' (a misnomer, when active). > And functions dynamically provide different keymaps > for different active-minibuffer contexts/uses. > > This is how being in minibuffer-inactive-mode (which > > does have its own key map) "worked" for so long. > Yes. It just means that `minibuffer-inactive-mode' > is a do-nothing when the minibuffer is active. > 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 don't really see that anything is missing or broken. > > The OP of this bug tells me that minor modes which maintain lists of > > "valid" major modes they work in, included minibuffers by including > > minibuffer-inactive-mode in their lists. This sort of worked (except for > > the first time a minibuffer was used), but is undesirable. > 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. > > So the idea is to allow these minor modes to specify minibuffer-mode. > 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. It's entirely credible that these packages use lists of major modes, and that their use in an active minibuffer is appropriate. I'm not familiar with any of the three packages cited by the OP, but in previous discussions, we'd already been through talking about using `minibufferp'. > Can we see a recipe that demonstrates a real problem? > > I think there's a bug here, yes. I don't know of any particular minor > > mode, off hand, that is affected by this, but the OP assure me they > > exist. This isn't really the sort of bug that has recipes. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That, right there, hints of a non-bug, I think. That somebody is unable to configure a minor mode like she used to do doesn't feel like a non-bug to me. 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. > It sounds like a misunderstanding, to me. On whose part? -- Alan Mackenzie (Nuremberg, Germany).