From: Drew Adams <drew.adams@oracle.com>
To: Alan Mackenzie <acm@muc.de>
Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>
Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Date: Mon, 22 Mar 2021 17:09:32 +0000 [thread overview]
Message-ID: <SA2PR10MB4474EFA866F722642F468CF3F3659@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <YFjFcr15EUyNmRh0@ACM>
> 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.
next prev parent reply other threads:[~2021-03-22 17:09 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 0:57 bug#47150: 28.0.50; Incorrect major-mode in minibuffer styang
2021-03-15 1:02 ` bug#47150: Emacs bug#47150 " Sheng Yang
2021-03-15 7:59 ` bug#47150: " Alan Mackenzie
2021-03-15 18:15 ` Sheng Yang
2021-03-15 21:30 ` Alan Mackenzie
2021-03-15 21:58 ` Sheng Yang
2021-03-22 15:12 ` Alan Mackenzie
2021-03-22 15:52 ` bug#47150: [External] : " Drew Adams
2021-03-22 16:27 ` Alan Mackenzie
2021-03-22 17:09 ` Drew Adams [this message]
[not found] ` <878s6ft5ze.fsf_-_@miha-pc>
2021-03-22 18:38 ` bug#47150: [External] : " Drew Adams
2021-03-22 21:57 ` bug#47150: [External] : " Alan Mackenzie
2021-03-22 23:06 ` Drew Adams
2021-03-23 13:05 ` Alan Mackenzie
2021-03-23 15:44 ` Drew Adams
2021-03-22 18:12 ` Stefan Monnier
2021-03-22 18:08 ` Stefan Monnier
2021-03-22 18:40 ` bug#47150: [External] : " Drew Adams
2021-03-22 19:30 ` Stefan Monnier
2021-03-22 19:42 ` Drew Adams
2021-03-22 20:11 ` Stefan Monnier
2021-03-22 21:36 ` Drew Adams
2021-04-09 8:57 ` Sheng Yang
2021-04-12 10:18 ` Alan Mackenzie
2021-04-12 12:02 ` Sheng Yang
2021-04-12 14:01 ` Stefan Monnier
2021-04-12 16:15 ` Alan Mackenzie
2021-04-12 17:10 ` Stefan Monnier
2021-04-12 18:34 ` Alan Mackenzie
2021-04-12 20:46 ` Stefan Monnier
2021-04-18 11:14 ` Alan Mackenzie
2021-04-18 15:22 ` Stefan Monnier
2021-04-19 9:33 ` Alan Mackenzie
2021-04-19 17:30 ` Alan Mackenzie
2021-04-19 18:22 ` Stefan Monnier
2021-04-19 19:18 ` Sheng Yang
2021-04-19 19:35 ` Stefan Monnier
2021-04-19 19:47 ` Sheng Yang
2021-04-19 20:36 ` Stefan Monnier
2021-04-19 20:42 ` Sheng Yang
2021-04-20 10:25 ` Alan Mackenzie
2021-03-22 19:42 ` Alan Mackenzie
2021-03-22 20:03 ` Stefan Monnier
2021-03-22 18:24 ` bug#47150: [External] : " jakanakaevangeli
2021-03-23 7:18 ` bug#47150: [External] : " jakanakaevangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SA2PR10MB4474EFA866F722642F468CF3F3659@SA2PR10MB4474.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=47150@debbugs.gnu.org \
--cc=acm@muc.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.