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: Alan Mackenzie <acm <at> muc.de>
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Date: Mon, 22 Mar 2021 23:06:23 +0000

> > > However, on being reused, these buffers remained in
> > > minibuffer-inactive-mode rather than being restored to fundamental-mode.
> > > This is silly, and "obviously" a bug.  I fixed this bug by making an
> > > active minibuffer always be in fundamental-mode.
> 
> > I don't see why it's "silly" or "'obviously' a bug", sorry.
> 
> It's silly, because the mode is called "...-inactive-..." and the
> minibuffers were, at the time, active.  It was obviously a bug, because
> the major mode was different the first time the MB was used, from the
> subsequent times.

OK, silly mode name; agreed.
But how was the major mode different?
It remained `...inactive...', no?

Yes, it became actually active, but the mode
stayed `minibuffer-inactive-mode', right?

Is there something more going on than a poorly
named mode?

> > Yeah, I see that the doc string for `minibuffer-inactive-mode'
> > suggests that it's not used when the minibuffer is active.
> 
> > And that's effectively the case, though the mode name might
> > not reflect it.  There's _nothing to that mode_, apart from
> > its keymap, and its keymap is not used when the minibuffer
> > is active.  So the mode is there in name only.
> 
> I haven't checked whether its mode hook gets run, but I think it would
> (if anybody put any functions on it).

OK.  But does the mode ever get turned off,
once it's turned on (at minibuffer creation
presumably)?

I didn't think so.  My impression has been that
the mode remains `minibuffer-inactive-mode'.

I said that the behavior is "effectively" as if
that mode isn't in effect - its doc description
doesn't apply when the minibuffer is active.
But the mode is still `minibuffer-inactive-mode'
- or so I've thought.

> > What if the name of that mode was just `minibuffer'
> > or `foobar'?  Would you think/feel the same way about
> > needing to add another mode?  Seriously - please think
> > about this.
> 
> Well the behaviour of a minibuffer is so utterly different when it is
> active, from when it is inactive (e.g., in a minibuffer-only frame) that
> having them share a major mode doesn't seem right.  But I take the point.

It's a mode for the minibuffer; that's all.

Yes, the behavior's different when it's inactive vs
active - it's the key bindings.  But the behavior's
different when you use `completing-read' from when
you use `read-string' or whatever - again, it's the
key bindings (keymaps).

Should we have a different major mode for each kind
of active behavior - completing-read, read-file-name,
read-buffer, read-number, read-expression,...

All of those behaviors are different - different
key binding.  By your reasoning we should have
different major modes for them, no?

> > `minibuffer-inactive-mode' is, yes, a misnomer ...
> > except that its (only?) purpose was to provide a keymap
> > for use when the minibuffer is inactive.  And the keymap
> > name (with "inactive") comes free with the mode creation.
> 
> > If you really feel a need to clean something up here,
> > consider changing that mode name (but aliasing the old
> > one, for compatibility).  To me, that would be the OCD
> > end of story.
> 
> > > An active minibuffer doesn't use its own key map -
> > > it uses the key map supplied to it by the calling function.
> 
> > Exactly.  Exactly.  Exactly.
> 
> > An active minibuffer doesn't have a separate mode from
> > `minibuffer-inactive-mode' (a misnomer, when active).
> 
> > And functions dynamically provide different keymaps
> > for different active-minibuffer contexts/uses.
> 
> > > This is how being in minibuffer-inactive-mode (which
> > > does have its own key map) "worked" for so long.
> 
> > Yes.  It just means that `minibuffer-inactive-mode'
> > is a do-nothing when the minibuffer is active.
> 
> > But what's the point of providing a new mode for when
> > it's active?  What could/would/will anyone _do_ with
> > such a mode?  Keymaps are all that really matter here,
> > and giving the new mode its own keymap would be useless.
> 
> > (At least it _should_ be useless.  And it will be ...
> > until someone decides that for "consistency" or
> > "completeness" its keymap should really take effect.)
> 
> That's about the only thing I worry about (along with
> the possibility of using a mode hook - but we have that
> danger with minibuffer-inactive-mode-hook anyway, and
> it doesn't appear to have caused trouble, as yet.)

I really don't see the mode hook (on any such mode)
being a problem in practice.

Currently, the minibuffer is (I think) _always_ in
`minibuffer-inactive-mode'.  Its mode hook only ever
kicks in when a minibuffer buffer is created.

OK, that does happen occasionally, for recursive
minibuffers.  But I think worrying about its mode
hook is fruitless and needless.

> > Sounds like pilot error (misunderstanding) to me.  Did
> > OP demonstrate a real need to include a minibuffer mode
> > in such minor-mode lists?  IOW, where's the beef (bug)?
> 
> To quote the OP:
> 
> >>>> Packages depend on it [the major mode], to name a few: lispy,
> >>>> smartparens, and telega.

That doesn't answer the question about _need_.
What's the real need for them to do so?  That
would make the bug understandable as a bug.

> > Why?  What's the need?  Sorry, but I don't get it.  It
> > all sounds quite vague, as if someone thought that s?he
> > really needed to specify a minibuffer mode in those
> > minor-mode lists, and that need wasn't (isn't) real.
> 
> It's entirely credible that these packages use lists of major modes, and
> that their use in an active minibuffer is appropriate.

Sure, I get that (although it's abstract).  But can't
they just either special-case the minibuffer mode or
explicitly include it in their lists:
`minibuffer-inactive-mode'?

Do we even know whether adding that major mode to their
lists would solve their problem?

> I'm not familiar with any of the three packages cited
> by the OP,

Nor am I.

> but in previous discussions, we'd already been through
> talking about using `minibufferp'.

Dunno what that was about.  See previous: the minibuffer
has a major mode, `minibuffer-inactive-mode', doesn't it?
Why is that harder to handle than some other major mode?

> > > This isn't really the sort of bug that has recipes.
> > That, right there, hints of a non-bug, I think.
> 
> That somebody is unable to configure a minor mode like
> she used to do...

Sorry, hold on.  Like she used to do?  So something was
changed?  Do you mean used to before Stefan gave the
minibuffer the major mode `minibuffer-inactive-mode'?
That was a while back.  Did that cause a regression for
the OP?

> But maybe your idea of just renaming
> minibuffer-inactive-mode (with an alias) and using it
> for active MBs might be the best way to fix it.

Seems straightforward to me, but I may well be missing
something.

As for "using it for active MBs" - there's nothing to
change (IIUC): that misnamed mode is already used for
active (and inactive) MBs (IIUC).

It's just that the behavior of the minibuffer changes,
depending on whether it's active and, if so, keymap is
used for the reading.

> > It sounds like a misunderstanding, to me.
> On whose part?

I was thinking OP.  I was thinking that it should be
sufficient to just include `minibuffer-inactive-mode'
in their major-mode lists.

But I admit to a poor understanding of the problem.

Previous Next

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