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: Sun, 18 Apr 2021 11:14:20 +0000 Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@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="6203"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 18 13:15:16 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 1lY5OV-0001U7-Ng for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 13:15:15 +0200 Original-Received: from localhost ([::1]:46900 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lY5OU-0002hn-RA for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 07:15:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lY5OI-0002g2-44 for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 07:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34023) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lY5OH-0003w5-Qt for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 07:15:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lY5OH-0003K1-Mb for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 07:15:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Apr 2021 11:15: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.161874447112715 (code B ref 47150); Sun, 18 Apr 2021 11:15:01 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 18 Apr 2021 11:14:31 +0000 Original-Received: from localhost ([127.0.0.1]:45569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY5Nn-0003J1-CN for submit@debbugs.gnu.org; Sun, 18 Apr 2021 07:14:31 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:61075 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lY5Nl-0003Ih-Hp for 47150@debbugs.gnu.org; Sun, 18 Apr 2021 07:14:30 -0400 Original-Received: (qmail 85197 invoked by uid 3782); 18 Apr 2021 11:14:21 -0000 Original-Received: from acm.muc.de (p2e5d56e2.dip0.t-ipconnect.de [46.93.86.226]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 18 Apr 2021 13:14:21 +0200 Original-Received: (qmail 6152 invoked by uid 1000); 18 Apr 2021 11:14:20 -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:204321 Archived-At: Hello, Stefan. On Mon, Apr 12, 2021 at 16:46:34 -0400, Stefan Monnier wrote: [ .... ] > > Am I right in thinking that your main worry is the hook not getting > > called at the end of every MB action? > No. My worries are: > - not having the minibuffer-inactive-mode-map active when the minibuffer > is inactive. > - running minibuffer-inactive-mode-hook at other times than when the > minibuffer becomes inactive. > >> > The idea here is to avoid the proliferation of unneeded major modes. > >> Major modes are cheap. There is no problem with proliferation. > > That's not true - the OP has found a problem, in that some minor modes > > switch themselves on when (memq major-mode foo-mode-list). > > The current situation, fundamental-mode (active), > > minibuffer-inactive-mode (inactive) is causing problems with that > > scheme, hence this bug. > Their code was buggy/naive, will be broken no matter what we choose > to do (except for sticking to what we had in Emacs<28), and is easy to > fix in a backward compatible way using `minibufferp`. This would make a special case of minibuffer_mode, which would require minibufferp, when other modes would be matched with (memq major-mode foo-list). > So I don't think this matters very much. This was the meat of the OP's bug report. ;-) > Most cases of (eq major-mode ) are bugs waiting to bite you. I don't see this at the moment, but I won't ask you to elaborate here and now. > > How about having just minibuffer-mode, and calling it at the end of > > every MB action (as was previously done with > > minibuffer-inactive-mode), but not at the start of a MB action? > > This will call the mode hook at the same times as the > > m-inactive-m-hook used to be called, and reset the MB's keymap to > > the inactive map at the same time. > IOW just renaming `minibuffer-inactive-mode` to `minibuffer-mode` and > calling it one extra time at the very beginning? Yes. It's that "one extra time at the very beginning" which makes it nasty. :-( > Technically, it won't break any of my uses, of course, but then it leads > to rather counter-intuitive situations where "the keymap of > `minibuffer-mode`" is almost never used (it's only active when the > minibuffer is inactive), "the hook of `minibuffer-mode`" is run not when > entering a minibuffer but when leaving it, ... > Also, there's a natural desire to occasionally use other major modes in > the minibuffer (e.g. for `M-:`), so it would be very natural to make > them derived modes of `minibuffer-mode` except that it would then > inherit from a keymap which makes no sense in an active minibuffer. > It just doesn't seem right at all. Yes, it has disadvantages. You're right. > What's wrong with just making a new mode > (define-derived-mode minibuffer-mode nil "Minibuffer" > "Mode used inside minibuffers.") > and using that instead of `fundamental-mode`. The scheme you propose, having two modes minibuffer-\(inactive-\)?mode also has disadvantages, pointed out by Drew in his post in this thread from Date: Mon, 22 Mar 2021 17:09:32 +0000 - minibuffer-mode would be a useless mode, just a placeholder; it has a key map, a syntax table, an abbreviation table which will never be used (OK, some of these can be specified nil in define-derived-mode), a redundant mode hook (there exist minibuffer-setup-hook and minibuffer-exit-hook). These can surely only cause trouble down the line. So Drew is right, too. The problem is, we're in an anomalous situation. Major modes aren't really the right tool for the minibuffer, but not using major modes isn't any better. Anything we do here is bad. :-( Over the past few days, I've come to the conclusion that having two modes for the minibuffer is the lesser evil than having just one mode whose mode function would be called at the end of a minibuffer use. The deciding criterion, which might seem minor, is that with the one mode, we'd have to call it "one extra time at the very beginning" as discussed above. So I intend to leave minibuffer-inactive-mode more or less alone, and to implement minibuffer-mode, which will get called at the start of each minibuffer use, flushing out old stuff from any previous minibuffer (non-)use. > Stefan -- Alan Mackenzie (Nuremberg, Germany).