[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47150: 28.0.50; Incorrect major-mode in minibuffer
From: |
Alan Mackenzie |
Subject: |
bug#47150: 28.0.50; Incorrect major-mode in minibuffer |
Date: |
Mon, 22 Mar 2021 19:42:10 +0000 |
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).
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, (continued)
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Stefan Monnier, 2021/03/22
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Stefan Monnier, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Stefan Monnier, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Stefan Monnier, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/22
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer,
Alan Mackenzie <=
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Stefan Monnier, 2021/03/22
bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, jakanakaevangeli, 2021/03/22
bug#47150: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer, jakanakaevangeli, 2021/03/23