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: 28.0.50; Incorrect major-mode in minibuffer Date: Mon, 22 Mar 2021 19:42:10 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@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="28322"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Mon Mar 22 20:44:40 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 1lOQTf-0007Bb-Le for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 20:44:39 +0100 Original-Received: from localhost ([::1]:36854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOQTe-0004by-NJ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 15:44:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOQS9-0003Of-Sw for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 15:43:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47183) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lOQS6-0006dw-6N for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 15:43:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lOQS6-0007kk-0U for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 15:43: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 19:43: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.161644213929734 (code B ref 47150); Mon, 22 Mar 2021 19:43:01 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 19:42:19 +0000 Original-Received: from localhost ([127.0.0.1]:58723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQRO-0007jV-VB for submit@debbugs.gnu.org; Mon, 22 Mar 2021 15:42:19 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:28519 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lOQRN-0007jC-OO for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 15:42:18 -0400 Original-Received: (qmail 74161 invoked by uid 3782); 22 Mar 2021 19:42:10 -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 20:42:10 +0100 Original-Received: (qmail 8616 invoked by uid 1000); 22 Mar 2021 19:42:10 -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:202865 Archived-At: Hello, Stefan. On Mon, Mar 22, 2021 at 14:08:46 -0400, Stefan Monnier wrote: > [ Hi, perpetrator of `minibuffer-inactive-mode` speaking. ] :-) > > minibuffer-inactive-mode: the critical thing here is "inactive", which > > means "doing nothing", or "not in use", or even "sleeping". The > > opposite word is "active". From its name, this major mode was never > > intended for use in active minibuffers, > That's right. > > but somehow nobody noticed that the buffer never got shifted out of > > minibuffer-inactive-mode when it came to be used again. > I did notice, but it didn't seem to cause any harm and I didn't want to > get into the discussion in which we are now, so I left things as > they stood. Umm. Maybe I should apologise, then. ;-) > > I've been fixing things in minibuf.c recently, and when I discovered > > this anomaly, I fixed it, so that an active minibuffer now runs in > > fundamental-mode, as originally intended. I did wonder why there was no > > "minibuffer-mode". But it was clear from the code that whoever wrote it > > intended minibuffers to use fundamental-mode whilst active. > I'm in favor of introducing a `minibuffer-mode`. Thanks. > Part of the question is also when and how that mode is activated (since > activating such a mode has the effect of deleting the local variables). > I think we should call `minibuffer-mode` every time we (re)activate > a minibuffer. At the moment, fundamental-mode is activated from read_minibuf after " *Minibuf-n*" has been selected, but before minibuffer-setup-hook is called (which is as it should be). It would be easy to call minibuffer-mode instead. So we are in agreement, here. > >> For my case, I want automatic paren pairing and editing in > >> eval-expression. > > That does indeed suggest we really want a minibuffer-mode, rather than > > just fundamental-mode. But surely, the parenthesis pairing will be > > dependant on the sort of text you're typing into the minibuffer, so it > > can't really be connected with, say, minibuffer-mode. > The way I see it, `eval-expression` would want to use a new major mode > that derives from `minibuffer-mode`. And more generally > `read-from-minibuffer` should accept an argument that says which major > mode to use (I think it'd make sense to re-use the `keymap` argument > for that: if that argument is `functionp`, then treat it as a major > mode, if it's `keymapp` then use it as the keymap). > It would also provide a cleaner way to do what we currently do via the > `minibuffer-with-setup-hook` hack. Umm, why? Do we really need all this extra complexity? Having just spent an extended period of time struggling with minibuf.c, I'd be happier not to make it even more complicated. > >> Plus we also need a keymap for it, which is > >> minibuffer-inactive-mode-map. > > No. That keymap is very low functionality, and almost useless, as it's > > intended to be. > Indeed, the purpose of that keymap is that you can press `f` (for > example) into a minibuffer-only frame to open a file, but only when > there's no active minibuffer in that minibuffer-only frame. > >> It seems to me the minibuffer is always inactive? I tried M-x, > >> M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1. Is this > >> a mistake and the offending commit was trying to fix this > >> inconsistency? > > Very much so! > BTW: thank you for that. A pleasure! > > So, a quick summary: (i) the change in the minibuffer's major mode to > > fundamental-mode was intended; (ii) there may be some problems in some > > packages because of this; > The minibuffer used to be "always" in fundamental mode in Emacs<24 > (since there was no `minibuffer-inactive-mode` back then), so I'm not > too worried. As you agreed earlier, I think we should put minibuffer-mode in place for those minor modes which maintain lists of valid (for them) major modes, and suchlike. > Stefan -- Alan Mackenzie (Nuremberg, Germany).