Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

From: Drew Adams <[email-masked]>
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.)