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: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>, Alan Mackenzie <acm <at> muc.de>, Sheng Yang <styang <at> fastmail.com>
Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Date: Mon, 22 Mar 2021 19:42:21 +0000

> >> I'm in favor of introducing a `minibuffer-mode`.
> > Why?
> 
> Because that's already what "fundamental-mode + minibuffer-local-map"
> is, tho without the benefit of all the associated conventions of a major
> mode (e.g. C-h m to name just one).
> 
> >> 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.
> > Why?
> 
> So a minibuffer isn't affected by what happened in its previous invocation.

Can you give a quick example? I don't think I've
ever noticed a minibuffer affected by what happened
in a previous invocation.

> >> The way I see it, `eval-expression` would want to use a new major mode
> >> that derives from `minibuffer-mode`.
> > Why change the major mode?
> 
> Why not.  That's already what `eval-expression` does, except it does it
> piecemeal instead of via the well known major-mode concept.
> 
> > What's involved, besides keymaps?
> 
> In the case of `eval-expression, potentially anything that applies to
> a normal buffer seems to be applicable, e.g. indentation,
> show-paren-mode, eldoc, font-lock, flymake, company-mode, you name it...

Hm.  Be careful what you wish for.

> >> It would also provide a cleaner way to do what we currently do via the
> >> `minibuffer-with-setup-hook` hack.
> > Really?  Everything that someone might do on that
> > hook you would have passed as a function arg?
> 
> I don't think we could replace all uses of `minibuffer-with-setup-hook`
> with that, no, at least not without additional changes (since my
> suggestion only covers code which currently directly uses
> `read-from-minibuffer`, so we'd at least have to change
> `completing-read` so it too can take a major-mode as argument).

Ugh.

> > Why would you find that cleaner?
> 
> If you don't know, it's because you haven't looked at the implementation
> of `minibuffer-with-setup-hook`, which is fundamentally inherently
> brittle (tho it's sufficiently tuned that it's normally never a problem
> in practice, of course).

I thought you were saying it would be cleaner for
_users_.  My question was/is how it would be cleaner
for users.

> > Right.  There was nothing missing before `minibuffer-inactive-mode'
> > was added, except possibly the corner case you mentioned for
> > a standalone minibuffer frame.  (And I use such a frame, and I've
> > never felt the need to use it in an "inactive" active way.)
> 
> Nobody forces you to use it.  It should be harmless.
> Have you suffered from the addition of `minibuffer-inactive-mode`?
> I can't remember seeing many bug reports about it (although I was
> worried when I added it).

Right.  That was my expectation too - harmless.
(Though your comment above, about "anything that
applies to a normal buffer makes me just a tiny
bit nervous now.)

And no, I've never suffered from `*-inactive-mode'.
I've never found a use for it either.

Can I ask what's wrong with what I suggested: One
mode, not two; just change the name and provide
a helpful doc-string that covers both active and
inactive?

Previous Next

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