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

[Drew Adams <drew.adams@oracle.com>]

> Things are already broken, slightly.

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

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

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.

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?

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.

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

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

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

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.
It sounds like a misunderstanding, to me.