[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in mini
From: |
Drew Adams |
Subject: |
bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer |
Date: |
Mon, 22 Mar 2021 17:09:32 +0000 |
> 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.
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, styang, 2021/03/14
- bug#47150: Emacs bug#47150 28.0.50; Incorrect major-mode in minibuffer, Sheng Yang, 2021/03/14
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Alan Mackenzie, 2021/03/15
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Sheng Yang, 2021/03/15
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Alan Mackenzie, 2021/03/15
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Sheng Yang, 2021/03/15
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Alan Mackenzie, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Alan Mackenzie, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer,
Drew Adams <=
- Message not available
- bug#47150: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Alan Mackenzie, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Alan Mackenzie, 2021/03/23
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/23
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Stefan Monnier, 2021/03/22
- bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Stefan Monnier, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Stefan Monnier, 2021/03/22
- bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer, Drew Adams, 2021/03/22