GNU bug report logs - #47150
28.0.50; Incorrect major-mode in minibuffer

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Alan Mackenzie <acm <at> muc.de>
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>, Sheng Yang <styang <at> fastmail.com>
Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Date: Mon, 22 Mar 2021 18:40:05 +0000

> I'm in favor of introducing a `minibuffer-mode`.

Why?

> 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.

Why?

> The way I see it, `eval-expression` would want to use a new major mode
> that derives from `minibuffer-mode`.

Why change the major mode?  What's involved, besides
keymaps?  Does parenthesis pairing and such require
a major-mode change?

> 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).

Why?  What's the use case for changing major modes?

> It would also provide a cleaner way to do what we currently do via the
> `minibuffer-with-setup-hook` hack.

Really?  Everything that someone might do on that
hook you would have passed as a function arg?  Why
would you find that cleaner?

> >> 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.

AFAICT, the only "offense" was committed by the
misleading mode name.  I don't see why two (or
more...) major modes are needed.

> > 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.

Right.  There was nothing missing before
`minibuffer-inactive-mode' was added, except possibly
the corner case you mentioned for a standalone minibuffer
frame.  (And I use such a frame, and I've never felt the
need to use it in an "inactive" active way.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.