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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Apr 18, 2021 at 11:22:18 -0400, Stefan Monnier wrote:
> >> Their code was buggy/naive, will be broken no matter what we choose
> >> to do (except for sticking to what we had in Emacs<28), and is easy
> >> to fix in a backward compatible way using `minibufferp`.

> > This would make a special case of minibuffer_mode, which would
> > require minibufferp, when other modes would be matched with (memq
> > major-mode foo-list).

> No, you could also use (derived-mode-p <foo-list>) instead of
> (minibufferp).

I can't see how that's different in principle from (memq major-mode
foo-list).  But that's probably not important any more.

> >> > How about having just minibuffer-mode, and calling it at the end
> >> > of every MB action (as was previously done with
> >> > minibuffer-inactive-mode), but not at the start of a MB action?
> >> > This will call the mode hook at the same times as the
> >> > m-inactive-m-hook used to be called, and reset the MB's keymap to
> >> > the inactive map at the same time.

> >> IOW just renaming `minibuffer-inactive-mode` to `minibuffer-mode`
> >> and calling it one extra time at the very beginning?

> > Yes.  It's that "one extra time at the very beginning" which makes
> > it nasty.  :-(

> Could you explain the problem you see with calling it one extra time?

That extra time would be calling it just before the MB gets used.  Every
other call to minibuffer-mode would be just after MB use.  This is ugly,
and one way or another, would be bound to cause problems.

> > The scheme you propose, having two modes
> > minibuffer-\(inactive-\)?mode also has disadvantages, pointed out by
> > Drew in his post in this thread from Date: Mon, 22 Mar 2021 17:09:32
> > +0000 - minibuffer-mode would be a useless mode, just a placeholder;
> > it has a key map, a syntax table, an abbreviation table which will
> > never be used (OK, some of these can be specified nil in
> > define-derived-mode), a redundant mode hook (there exist
> > minibuffer-setup-hook and minibuffer-exit-hook).  These can surely
> > only cause trouble down the line.  So Drew is right, too.

> These "extras" haven't caused any trouble in all the other major modes
> where they're not used (including minibuffer-inactive-mode), so it seems
> to me like you're worried about something perfectly harmless.

Maybe they won't cause trouble, but they can't do anything positive.
That was what I meant by "only".  :-)

> > The problem is, we're in an anomalous situation.  Major modes aren't
> > really the right tool for the minibuffer, but not using major modes
> > isn't any better.  Anything we do here is bad.  :-(

> I disagree.  The minibuffers are normal buffers, and the more normal we
> can make them, the better.  Clearly, the major modes that make sense in
> a minibuffer will almost invariably be different from the major modes
> that make sense in other buffers, but that doesn't mean that the concept
> of "major mode" is wrong for minibuffers.  Not at all.
> On the contrary, from where I stand, it is The Right Thing.

OK, please add an IMHO to my last paragraph.  While hacking minibuf.c,
the major mode stuff didn't feel natural to me.  It felt like something
forced into something which didn't need it.  That's just my view on it.

> I'd argue that we're de-facto already using major modes, just without
> the advantages that come from having conventions.
> E.g. `minibuffer-setup-hook` is the hook for the "parent major mode"
> of all the minibuffer "major modes".  The `minibuffer-*-map` are the
> keymaps of the various different "major modes".

> The advantages we can gain by bringing the conventions of "real" major
> modes would be for example that `C-h m` would give useful information
> when used in the minibuffer.

I posted a patch for this yesterday.  In the documentation bit, I
strongly advised against using minibuffer-mode-hook, instead directing
users to minibuffer-setup-hook and minibuffer-exit-hook.  Was this the
right thing to write?

> > Over the past few days, I've come to the conclusion that having two
> > modes for the minibuffer is the lesser evil than having just one
> > mode whose mode function would be called at the end of a minibuffer
> > use.  The deciding criterion, which might seem minor, is that with
> > the one mode, we'd have to call it "one extra time at the very
> > beginning" as discussed above.

> > So I intend to leave minibuffer-inactive-mode more or less alone,
> > and to implement minibuffer-mode, which will get called at the start
> > of each minibuffer use, flushing out old stuff from any previous
> > minibuffer (non-)use.

> Sounds good to me ;-)

Excellent!  We've disagreed about a few things, but in the end they've
made no difference to the changes to be made.  :-)

As I said, I posted a patch yesterday.  We'll see how much reaction
there is to it, and after dealing with that reaction I'll commit the
patch and close the bug.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).