From: Alan Mackenzie <acm@muc.de>
To: Drew Adams <drew.adams@oracle.com>
Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, acm@muc.de
Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Date: Tue, 23 Mar 2021 13:05:29 +0000 [thread overview]
Message-ID: <YFnnmfATiO9QU4xP@ACM> (raw)
In-Reply-To: <SA2PR10MB44741648B052D1BB76F9F8B7F3659@SA2PR10MB4474.namprd10.prod.outlook.com>
Hello, Drew.
Some confusion has arisen, which I'd like to try and clear up right at
the top of this post.
I have recently (in the last few months) changed the modes used by
minibuffers. The OP for this bug has drawn attention to the
difficulties these changes have caused.
Before my changes:
(i) An active minibuffer, the first time it was used, was in fundamental
mode. In subsequent uses it was in minibuffer-inactive-mode.
(ii) An inactive minibuffer was always in minibuffer-inactive-mode.
After my changes:
(iii) An active minibuffer is always in fundamental mode.
(iv) An inactive minibuffer is always in minibuffer-inactive-mode.
On Mon, Mar 22, 2021 at 23:06:23 +0000, Drew Adams wrote:
[ .... ]
> OK, silly mode name; agreed.
> But how was the major mode different?
> It remained `...inactive...', no?
See (i) above.
[ .... ]
> Is there something more going on than a poorly
> named mode?
See (i): the fact that the first use of a minibuffer was in a different
mode from subsequent uses.
[ .... ]
> > I haven't checked whether its mode hook gets run, but I think it would
> > (if anybody put any functions on it).
> OK. But does the mode ever get turned off,
> once it's turned on (at minibuffer creation
> presumably)?
See (iii) and (iv) above.
> I didn't think so. My impression has been that
> the mode remains `minibuffer-inactive-mode'.
This used to be the case, but is no longer so.
[ .... ]
> > > 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.
> > Well the behaviour of a minibuffer is so utterly different when it is
> > active, from when it is inactive (e.g., in a minibuffer-only frame) that
> > having them share a major mode doesn't seem right. But I take the point.
> It's a mode for the minibuffer; that's all.
> Yes, the behavior's different when it's inactive vs
> active - it's the key bindings. But the behavior's
> different when you use `completing-read' from when
> you use `read-string' or whatever - again, it's the
> key bindings (keymaps).
I think there's a difference here between "utterly different" and
"slightly different". The question is whether the utterly-slightly
distinction is sufficient to justify having two modes. You clearly think
not. I'm, as yet, undecided.
[ .... ]
> > > 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.)
> > That's about the only thing I worry about (along with
> > the possibility of using a mode hook - but we have that
> > danger with minibuffer-inactive-mode-hook anyway, and
> > it doesn't appear to have caused trouble, as yet.)
> I really don't see the mode hook (on any such mode)
> being a problem in practice.
Probably not
[ .... ]
> > > 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)?
> > To quote the OP:
> > >>>> Packages depend on it [the major mode], to name a few: lispy,
> > >>>> smartparens, and telega.
> That doesn't answer the question about _need_.
> What's the real need for them to do so? That
> would make the bug understandable as a bug.
I honestly don't see the problem in accepting this bug as a real bug.
After several exchanges (earlier on in the thread), the OP's current
difficulties are clear, and they were caused by my recent changes in the
minibuffer mode handling.
[ .... ]
> Do we even know whether adding that major mode to their
> lists would solve their problem?
I think so, yes.
[ .... ]
> > But maybe your idea of just renaming minibuffer-inactive-mode (with
> > an alias) and using it for active MBs might be the best way to fix
> > it.
> Seems straightforward to me, but I may well be missing
> something.
There would be minor details to sort out, like does the renamed
minibuffer-mode get rerun each time the minibuffer is used, and things
like that.
[ .... ]
> > > It sounds like a misunderstanding, to me.
> > On whose part?
> I was thinking OP. I was thinking that it should be
> sufficient to just include `minibuffer-inactive-mode'
> in their major-mode lists.
This was what was previously done, and because it no longer works is the
cause of the bug report.
> But I admit to a poor understanding of the problem.
I'm not sure about that. ;-). Thanks indeed for the idea of just having
a single minibuffer-mode, rather than two modes.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2021-03-23 13:05 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
[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 [this message]
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=YFnnmfATiO9QU4xP@ACM \
--to=acm@muc.de \
--cc=47150@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
/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.