bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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