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

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Drew Adams <drew.adams <at> oracle.com>
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 21:57:37 +0000

Hello, Drew.

On Mon, Mar 22, 2021 at 17:09:32 +0000, Drew Adams wrote:
> > Things are already broken, slightly.

> I don't see that you say how things are (even slightly) broken.

I think I meant that with regard to the philosophy "if it isn't broken,
don't fix it", in that I had already fixed it, so a further fix in the
vicinity wouldn't do any further damage.

> > In my recent enhancements to the minibuffer handling, I noticed that
> > minibuffers (the actual buffers) began life in fundamental-mode, got
> > used, then on termination were put into minibuffer-inactive-mode.

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

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

> That's why I expect that your change will have no real
> effect.  But I'm wary of it - let sleeping dogs lie.  And
> if it does, in fact, have no real effect, then why make
> your change?

Because of the negative effect reported by Sheng Yang, the OP.

> This seems like a solution in search of a problem.

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

> `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 don't really see that anything is missing or broken.

> > The OP of this bug tells me that minor modes which maintain lists of
> > "valid" major modes they work in, included minibuffers by including
> > minibuffer-inactive-mode in their lists.  This sort of worked (except for
> > the first time a minibuffer was used), but is undesirable.

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

> > So the idea is to allow these minor modes to specify minibuffer-mode.

> 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.  I'm not familiar
with any of the three packages cited by the OP, but in previous
discussions, we'd already been through talking about using `minibufferp'.

> Can we see a recipe that demonstrates a real problem?

> > I think there's a bug here, yes.  I don't know of any particular minor
> > mode, off hand, that is affected by this, but the OP assure me they
> > exist.  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
doesn't feel like a non-bug to me.  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.

> It sounds like a misunderstanding, to me.

On whose part?

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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