GNU bug report logs - #47150
28.0.50; Incorrect major-mode in minibuffer

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: styang@HIDDEN; dated Mon, 15 Mar 2021 00:58:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 18 Apr 2021 11:14:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 07:14:31 2021
Received: from localhost ([127.0.0.1]:45569 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY5Nn-0003J1-CN
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 07:14:31 -0400
Received: from colin.muc.de ([193.149.48.1]:61075 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lY5Nl-0003Ih-Hp
 for 47150 <at> debbugs.gnu.org; Sun, 18 Apr 2021 07:14:30 -0400
Received: (qmail 85197 invoked by uid 3782); 18 Apr 2021 11:14:21 -0000
Received: from acm.muc.de (p2e5d56e2.dip0.t-ipconnect.de [46.93.86.226])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 18 Apr 2021 13:14:21 +0200
Received: (qmail 6152 invoked by uid 1000); 18 Apr 2021 11:14:20 -0000
Date: Sun, 18 Apr 2021 11:14:20 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <YHwUjL5Zgmfw7n9v@ACM>
References: <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
 <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
 <YHQeZ6DhP5uiWu8Q@ACM>
 <8cbe7629-2091-45d3-9424-46444d7a4633@HIDDEN>
 <jwv4kgbeh81.fsf-monnier+emacs@HIDDEN> <YHRyGiTt7h1KsD/+@ACM>
 <jwvh7kbcu3a.fsf-monnier+emacs@HIDDEN> <YHSSug388+A3i0OP@ACM>
 <jwvo8ejb66y.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvo8ejb66y.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Sheng Yang <styang@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Mon, Apr 12, 2021 at 16:46:34 -0400, Stefan Monnier wrote:

[ .... ]

> > Am I right in thinking that your main worry is the hook not getting
> > called at the end of every MB action?

> No.  My worries are:
> - not having the minibuffer-inactive-mode-map active when the minibuffer
>   is inactive.
> - running minibuffer-inactive-mode-hook at other times than when the
>   minibuffer becomes inactive.

> >> > The idea here is to avoid the proliferation of unneeded major modes.
> >> Major modes are cheap.  There is no problem with proliferation.
> > That's not true - the OP has found a problem, in that some minor modes
> > switch themselves on when (memq major-mode foo-mode-list).
> > The current situation, fundamental-mode (active),
> > minibuffer-inactive-mode (inactive) is causing problems with that
> > scheme, hence this bug.

> 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).

> So I don't think this matters very much.

This was the meat of the OP's bug report.  ;-)

> Most cases of (eq major-mode <foo>) are bugs waiting to bite you.

I don't see this at the moment, but I won't ask you to elaborate here
and now.

> > 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.  :-(

> Technically, it won't break any of my uses, of course, but then it leads
> to rather counter-intuitive situations where "the keymap of
> `minibuffer-mode`" is almost never used (it's only active when the
> minibuffer is inactive), "the hook of `minibuffer-mode`" is run not when
> entering a minibuffer but when leaving it, ...

> Also, there's a natural desire to occasionally use other major modes in
> the minibuffer (e.g. for `M-:`), so it would be very natural to make
> them derived modes of `minibuffer-mode` except that it would then
> inherit from a keymap which makes no sense in an active minibuffer.

> It just doesn't seem right at all.

Yes, it has disadvantages.  You're right.

> What's wrong with just making a new mode

>     (define-derived-mode minibuffer-mode nil "Minibuffer"
>       "Mode used inside minibuffers.")

> and using that instead of `fundamental-mode`.

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.

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.  :-(

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.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 20:46:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 12 16:46:50 2021
Received: from localhost ([127.0.0.1]:58220 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lW3SL-0007ZD-HS
	for submit <at> debbugs.gnu.org; Mon, 12 Apr 2021 16:46:50 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42844)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lW3SJ-0007U3-Sh
 for 47150 <at> debbugs.gnu.org; Mon, 12 Apr 2021 16:46:48 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 550671001D2;
 Mon, 12 Apr 2021 16:46:42 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 170AD100040;
 Mon, 12 Apr 2021 16:46:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618260396;
 bh=nK4/7wcElqujNXZfLAwpuU8FyUh5DlBokFvF2tOvnVY=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=DaRXj00Pl/yvCMqTazAaog1uKIlLZgjxmv0ZwaE0DRRj+CivHFb02+qJ9Q5Jj6qrp
 lQkgeeC/c/y3tNFsJqXFhVv2sgQasp5+B9/LhLtj3ZTzghNaYUhVhwDaUp7u2tBEOs
 +PbR2GHHaDNHmfEdhWTgruJ1W80Q5smLacE+E6yMP8V8pi50XT8eA53HeK2OZGfP+s
 +GNk7R1uLk9GKyavoCZOsvRPTuQ9AobOIufTX0/P/5ahkbL3CU7JCqEguFhLiFmgC2
 OpCOyUsa/wSikeVEz8Cx7L161KExsFdzSb0HyoXFx8TcKjxoJPVt4VmQgdRT/LNpjB
 nwGib/UsJZCFA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8FAAD1204F6;
 Mon, 12 Apr 2021 16:46:35 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <jwvo8ejb66y.fsf-monnier+emacs@HIDDEN>
References: <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
 <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
 <YHQeZ6DhP5uiWu8Q@ACM>
 <8cbe7629-2091-45d3-9424-46444d7a4633@HIDDEN>
 <jwv4kgbeh81.fsf-monnier+emacs@HIDDEN> <YHRyGiTt7h1KsD/+@ACM>
 <jwvh7kbcu3a.fsf-monnier+emacs@HIDDEN> <YHSSug388+A3i0OP@ACM>
Date: Mon, 12 Apr 2021 16:46:34 -0400
In-Reply-To: <YHSSug388+A3i0OP@ACM> (Alan Mackenzie's message of "Mon, 12 Apr
 2021 18:34:34 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.000 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Sheng Yang <styang@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> OK, what you say is true, what I said above is also true - active
> minibuffers ran in minibuffer-inactive-mode

That was true "in name only" (i.e. only the value of the variable
`major-mode` reflected that).

>> The keymap and the hook are the main two features of
>> `minibuffer-inactive-mode`.
> Yes.  Possibly they're the only features.

Pretty much, yes.

> Am I right in thinking that your main worry is the hook not getting
> called at the end of every MB action?

No.  My worries are:
- not having the minibuffer-inactive-mode-map active when the minibuffer
  is inactive.
- running minibuffer-inactive-mode-hook at other times than when the
  minibuffer becomes inactive.

>> > The idea here is to avoid the proliferation of unneeded major modes.
>> Major modes are cheap.  There is no problem with proliferation.
> That's not true - the OP has found a problem, in that some minor modes
> switch themselves on when (memq major-mode foo-mode-list).
> The current situation, fundamental-mode (active),
> minibuffer-inactive-mode (inactive) is causing problems with that
> scheme, hence this bug.

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`.
So I don't think this matters very much.

Most cases of (eq major-mode <foo>) are bugs waiting to bite you.

> 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?

Technically, it won't break any of my uses, of course, but then it leads
to rather counter-intuitive situations where "the keymap of
`minibuffer-mode`" is almost never used (it's only active when the
minibuffer is inactive), "the hook of `minibuffer-mode`" is run not when
entering a minibuffer but when leaving it, ...

Also, there's a natural desire to occasionally use other major modes in
the minibuffer (e.g. for `M-:`), so it would be very natural to make
them derived modes of `minibuffer-mode` except that it would then
inherit from a keymap which makes no sense in an active minibuffer.

It just doesn't seem right at all.

What's wrong with just making a new mode

    (define-derived-mode minibuffer-mode nil "Minibuffer"
      "Mode used inside minibuffers.")

and using that instead of `fundamental-mode`.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 18:34:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 12 14:34:44 2021
Received: from localhost ([127.0.0.1]:58061 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lW1OW-0000Z6-Dq
	for submit <at> debbugs.gnu.org; Mon, 12 Apr 2021 14:34:44 -0400
Received: from colin.muc.de ([193.149.48.1]:28863 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lW1OU-0000Yr-6r
 for 47150 <at> debbugs.gnu.org; Mon, 12 Apr 2021 14:34:42 -0400
Received: (qmail 19682 invoked by uid 3782); 12 Apr 2021 18:34:35 -0000
Received: from acm.muc.de (p4fe15ca4.dip0.t-ipconnect.de [79.225.92.164])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 12 Apr 2021 20:34:35 +0200
Received: (qmail 8819 invoked by uid 1000); 12 Apr 2021 18:34:34 -0000
Date: Mon, 12 Apr 2021 18:34:34 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <YHSSug388+A3i0OP@ACM>
References: <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
 <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
 <YHQeZ6DhP5uiWu8Q@ACM>
 <8cbe7629-2091-45d3-9424-46444d7a4633@HIDDEN>
 <jwv4kgbeh81.fsf-monnier+emacs@HIDDEN> <YHRyGiTt7h1KsD/+@ACM>
 <jwvh7kbcu3a.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <jwvh7kbcu3a.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Sheng Yang <styang@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Mon, Apr 12, 2021 at 13:10:57 -0400, Stefan Monnier wrote:
> > Why?  Until very recently (? 2 months ago), minibuffer-inactive-mode
> > served for both active and inactive MBs.

> No: it was *activated* every time the minibuffer became inactive (and
> not when the minibuffer was becoming active), and its keymap was only
> active when the minibuffer was inactive.

OK, what you say is true, what I said above is also true - active
minibuffers ran in minibuffer-inactive-mode (apart from the first
invocation of a MB), getting their key maps from the calling Lisp
commands.  At the end of the MB action m-inactive-m was called.

> The keymap and the hook are the main two features of
> `minibuffer-inactive-mode`.

Yes.  Possibly they're the only features.

Am I right in thinking that your main worry is the hook not getting
called at the end of every MB action?

> > The idea here is to avoid the proliferation of unneeded major modes.

> Major modes are cheap.  There is no problem with proliferation.

That's not true - the OP has found a problem, in that some minor modes
switch themselves on when (memq major-mode foo-mode-list).  The current
situation, fundamental-mode (active), minibuffer-inactive-mode
(inactive) is causing problems with that scheme, hence this bug.

> > We don't seem to need two distinct modes here for the minibuffer.

> The two situations are very different, where the users expect very
> different behavior.

They are indeed very different, but that difference is entirely
accounted for by the key map (and optionally, the mode hook).

> > This is pretty much, but not quite, the same as how things were up until
> > recently.

> No, it's completely different: the difference may seem minor, but
> this minor reason is the raison d'tre of `minibuffer-inactive-mode`, so
> what you're suggesting is, in practice, the removal of
> `minibuffer-inactive-mode`.

I don't think that's right.  What I'm proposing is renaming it (with
temporary alias), and regularising what used to be an ugly situation.

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.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 17:11:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 12 13:11:13 2021
Received: from localhost ([127.0.0.1]:57943 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lW05h-0004sH-Dg
	for submit <at> debbugs.gnu.org; Mon, 12 Apr 2021 13:11:13 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47923)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lW05g-0004s5-7T
 for 47150 <at> debbugs.gnu.org; Mon, 12 Apr 2021 13:11:12 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 87F168081F;
 Mon, 12 Apr 2021 13:11:06 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7809780531;
 Mon, 12 Apr 2021 13:11:04 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618247464;
 bh=gPGZhxUILV+4RpmllZZJf2fahGZ/yn7yNYwAC39OBS4=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=GzQY3KHoCozJKDQFW5CC3rxAZNq1ACmK0CLzTJ9D/G8tyoqp5JwUpGJPgN/0chC5Y
 K9zT4Pgx2r91xaNB4oCT3sZo3at0D45v8oOh0907Or+vOyqu+Yk6TX2rN8aja4SX6F
 7OE8eUhht0aDHMX8Wdk+850mHIe2ViNWkg1GkCITC371RcNTgDGX0g7skXGq9l1tt/
 vhSIp5MQNsbXaCh/RBgVVftpHRje2MGLUoraf0cJEtkGmSE63RqoXzZkh09iBNosZd
 iXrMr8Vex4FS1Ola520PVop55bOCGLgIuPw0+FAMlWd0QCZ7V8uXz/dB0xHpkFpm/q
 YAdYTz94T7Jfw==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 18698120315;
 Mon, 12 Apr 2021 13:11:04 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <jwvh7kbcu3a.fsf-monnier+emacs@HIDDEN>
References: <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
 <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
 <YHQeZ6DhP5uiWu8Q@ACM>
 <8cbe7629-2091-45d3-9424-46444d7a4633@HIDDEN>
 <jwv4kgbeh81.fsf-monnier+emacs@HIDDEN> <YHRyGiTt7h1KsD/+@ACM>
Date: Mon, 12 Apr 2021 13:10:57 -0400
In-Reply-To: <YHRyGiTt7h1KsD/+@ACM> (Alan Mackenzie's message of "Mon, 12 Apr
 2021 16:15:22 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.049 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Sheng Yang <styang@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Why?  Until very recently (? 2 months ago), minibuffer-inactive-mode
> served for both active and inactive MBs.

No: it was *activated* every time the minibuffer became inactive (and
not when the minibuffer was becoming active), and its keymap was only
active when the minibuffer was inactive.

The keymap and the hook are the main two features of
`minibuffer-inactive-mode`.

> The idea here is to avoid the proliferation of unneeded major modes.

Major modes are cheap.  There is no problem with proliferation.

> We don't seem to need two distinct modes here for the minibuffer.

The two situations are very different, where the users expect very
different behavior.

> This is pretty much, but not quite, the same as how things were up until
> recently.

No, it's completely different: the difference may seem minor, but
this minor reason is the raison d'=EAtre of `minibuffer-inactive-mode`, so
what you're suggesting is, in practice, the removal of
`minibuffer-inactive-mode`.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 16:15:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 12 12:15:31 2021
Received: from localhost ([127.0.0.1]:57824 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lVzDn-0003R1-1Q
	for submit <at> debbugs.gnu.org; Mon, 12 Apr 2021 12:15:31 -0400
Received: from colin.muc.de ([193.149.48.1]:25439 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lVzDl-0003Qo-JL
 for 47150 <at> debbugs.gnu.org; Mon, 12 Apr 2021 12:15:30 -0400
Received: (qmail 25399 invoked by uid 3782); 12 Apr 2021 16:15:22 -0000
Received: from acm.muc.de (p4fe15ca4.dip0.t-ipconnect.de [79.225.92.164])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 12 Apr 2021 18:15:22 +0200
Received: (qmail 8223 invoked by uid 1000); 12 Apr 2021 16:15:22 -0000
Date: Mon, 12 Apr 2021 16:15:22 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <YHRyGiTt7h1KsD/+@ACM>
References: <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
 <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
 <YHQeZ6DhP5uiWu8Q@ACM>
 <8cbe7629-2091-45d3-9424-46444d7a4633@HIDDEN>
 <jwv4kgbeh81.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwv4kgbeh81.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Sheng Yang <styang@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Mon, Apr 12, 2021 at 10:01:28 -0400, Stefan Monnier wrote:
> >> To sum up, the minibuffer will always be in `minibuffer-mode',
> >> regardless of whether it is active or inactive.

> Please don't do that.  Make `minibuffer-mode` be the *parent* mode, yes.
> But keep `minibuffer-inactive-mode` as a separate major mode.

Why?  Until very recently (? 2 months ago), minibuffer-inactive-mode
served for both active and inactive MBs.  The idea is simply to rename
that mode to minibuffer-mode (with aliases for the old names).

The idea here is to avoid the proliferation of unneeded major modes.  We
don't seem to need two distinct modes here for the minibuffer.

> >> I think this will enable you to solve the problems you have.

> But it would be a regression since it would get rid of
> `minibuffer-inactive-mode`.

No, it would rename it; the only difference between -active- and
-inactive- would be the local key map in force.  This would revert to
minibuffer-mode-map (formerly known as ...-inactive-...) at the
termination of the minibuffer operation.

This is pretty much, but not quite, the same as how things were up until
recently.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 14:01:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 12 10:01:43 2021
Received: from localhost ([127.0.0.1]:57625 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lVx8J-0008Iw-Az
	for submit <at> debbugs.gnu.org; Mon, 12 Apr 2021 10:01:43 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24998)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lVx8G-0008Ii-LY
 for 47150 <at> debbugs.gnu.org; Mon, 12 Apr 2021 10:01:41 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 53D5580531;
 Mon, 12 Apr 2021 10:01:35 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CE113801AB;
 Mon, 12 Apr 2021 10:01:29 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1618236089;
 bh=48SMd8/6+TLB2hlqwSpcqEKg4Nl0bRNTXKUGzM92EuQ=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=O/aJaTe01m4Ooq6YrWT/ElxkK0+T1nTYOYq+wHtMW64D7qCKDMtryzSzoYIjFXyuR
 yvxe6RWVNwy7bCD/UCI+cMeJ1yoNmPw9Vf3l+eLu4YvTp00SQAzDMuPYDXyOHk0a4O
 KbiW1YKWfp5Gbr+IkpAyT6QhRcKaQXWTPxgf8ilqxWfmsZUkhpGqV7siWLJfzdWbw7
 iAbVnH3cH4yNSabcIe73ucyKLSba6Py5VBtDDpHH5QNm/UhqTyZba4WHu1A/JpKMIR
 J2Yz29rVgu6oROfqIltYEw0V1OrjaFEWr9HhtKnySAcg5bR6x/i4s20JKwUR83gTIX
 P0z4aMUXa6GsA==
Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 92D20120867;
 Mon, 12 Apr 2021 10:01:29 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: "Sheng Yang" <styang@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <jwv4kgbeh81.fsf-monnier+emacs@HIDDEN>
References: <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
 <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
 <YHQeZ6DhP5uiWu8Q@ACM>
 <8cbe7629-2091-45d3-9424-46444d7a4633@HIDDEN>
Date: Mon, 12 Apr 2021 10:01:28 -0400
In-Reply-To: <8cbe7629-2091-45d3-9424-46444d7a4633@HIDDEN> (Sheng
 Yang's message of "Mon, 12 Apr 2021 07:02:16 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.050 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Alan Mackenzie <acm@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> To sum up, the minibuffer will always be in `minibuffer-mode', regardless
>> of whether it is active or inactive.
>
Please don't do that.  Make `minibuffer-mode` be the *parent* mode, yes.
But keep `minibuffer-inactive-mode` as a separate major mode.

>> I think this will enable you to solve the problems you have.

But it would be a regression since it would get rid of `minibuffer-inactive-mode`.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 12:02:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 12 08:02:46 2021
Received: from localhost ([127.0.0.1]:56686 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lVvHB-000506-PY
	for submit <at> debbugs.gnu.org; Mon, 12 Apr 2021 08:02:46 -0400
Received: from out5-smtp.messagingengine.com ([66.111.4.29]:52923)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <styang@HIDDEN>) id 1lVvH9-0004zt-L3
 for 47150 <at> debbugs.gnu.org; Mon, 12 Apr 2021 08:02:44 -0400
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
 by mailout.nyi.internal (Postfix) with ESMTP id 2577A5C0049;
 Mon, 12 Apr 2021 08:02:38 -0400 (EDT)
Received: from imap2 ([10.202.2.52])
 by compute6.internal (MEProxy); Mon, 12 Apr 2021 08:02:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
 mime-version:message-id:in-reply-to:references:date:from:to:cc
 :subject:content-type; s=fm2; bh=1pT7tRGBxKgbcP3gUQU4nFI41qpR8Lc
 R2D2Jrkwof2g=; b=f15BPg4iq8yBGQeYILzj4MepTceP9I9pE5+KUwLDnvhJe1A
 x+uBluWJvYTAcVCFpiPOS6+WcKe6oRfvfPmKtGC/bhdXCzyfXxjpdGnGqChdmOqH
 n0oMeBnJYuf3++v+HnM4b//SjBm5SUOPINNMCxNjsfJLSLnlfFXYlXvlTdGwAszk
 voKremAklL8pPKIAVcJoIi4/icwRnMLHc52E0AjiFbGIgzzEMBaKAUg7mhVzJsYZ
 29zw/QaSsjLCe2aXVJFEMq6JWXJDHfM7jWHk1D/5T1ZurdnVq6NzBHK9/awaMHJY
 lhJS6OZ60QEzyAKqB721x2VBDhhyXfFb4PWUj2g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1pT7tR
 GBxKgbcP3gUQU4nFI41qpR8LcR2D2Jrkwof2g=; b=InOffulwbNC58F/3oeAsst
 EyRGLgHn3E/EiTwZp9ee7TbdeBV4VrWyjqM0GoWA2kLwuChWdooPcZabOJiNj+RY
 VbiOhMH64yKwUMzqfj5JXNWlcYhjs22wjHMo8CU/4Nkr60uHuLmQWbYtgtRP2PfB
 VW6ZzccSIuX4Umz0Xkpn0ciBBh8Nluy+I4eJPJvfzpCKcsyX2hIqIy0ajC7PSp+E
 E+RgD4EACubqEHGcjOAFYTJYtw7C/zFibJXnfVQoTioTieznF48Lio+PHYMSeEmx
 9inyPOROKySiESIcFaS/fg7EdWI1dPFzsTryHrApR/r3wZRUc4qI2jlp62qeX3GA
 ==
X-ME-Sender: <xms:3TZ0YPC6ePNcm7YtzMQPJisy-O9_noIRHluB0M4Fz704hblS3_6LvA>
 <xme:3TZ0YFhUkd9xqbxXyYqyuDGTDNKYtyuhVum0aZO4XoyScLTLCAz_jTHfAcF-8iTzZ
 Jd8hSyniJ3E9q70l7w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekjedggeekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfuhhgv
 nhhgucgjrghnghdfuceoshhthigrnhhgsehfrghsthhmrghilhdrtghomheqnecuggftrf
 grthhtvghrnhepheeluedtudffffegffeileettedvudeihefhvefgvdeivddttdeifeei
 geegveejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh
 epshhthigrnhhgsehfrghsthhmrghilhdrtghomh
X-ME-Proxy: <xmx:3TZ0YKlRKMs21TVA8TlDhlRO84MVBELI0F5gh5LctKkwd-LrbI9NaA>
 <xmx:3TZ0YBwHONShI1pUiy7LJMdQceg5XK2cFROogCQQLU6cuNu8CvE0Ug>
 <xmx:3TZ0YETzUcTxz0zBfr_kj2z0NJamWSQ6u9GXz1opq6Y6AsOelphwCg>
 <xmx:3jZ0YPJZBq6WbOquel2yifioDprc1JPd_FWmwO_9dYqPlRRrUVNc7w>
Received: by mailuser.nyi.internal (Postfix, from userid 501)
 id A5B85A00360; Mon, 12 Apr 2021 08:02:37 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249
Mime-Version: 1.0
Message-Id: <8cbe7629-2091-45d3-9424-46444d7a4633@HIDDEN>
In-Reply-To: <YHQeZ6DhP5uiWu8Q@ACM>
References: <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
 <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
 <YHQeZ6DhP5uiWu8Q@ACM>
Date: Mon, 12 Apr 2021 07:02:16 -0500
From: "Sheng Yang" <styang@HIDDEN>
To: "Alan Mackenzie" <acm@HIDDEN>
Subject: =?UTF-8?Q?Re:_[External]_:_bug#47150:_28.0.50;
 _Incorrect_major-mode_in_m?= =?UTF-8?Q?inibuffer?=
Content-Type: multipart/alternative; boundary=05f223638e384f30bb46cbec1eacd7de
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

--05f223638e384f30bb46cbec1eacd7de
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks for the quick response! The changes sound good to me.

On Mon, Apr 12, 2021, at 05:18, Alan Mackenzie wrote:
> Hello, Sheng.
>=20
> On Fri, Apr 09, 2021 at 03:57:01 -0500, Sheng Yang wrote:
> > Any update/decision on this? The discussions have been inactive for =
more than 2 weeks.
>=20
> Sorry, I got distracted by another project which turned out to be bigg=
er
> than expected.
>=20
> I will decide this, basically to follow Drew's suggestion, since he is=

> the only one with strong views on the subject.  What's more, I am now
> convinced he is right.  ;-)
>=20
> To sum up, the minibuffer will always be in `minibuffer-mode', regardl=
ess
> of whether it is active or inactive.  The minibuffer-mode key map will=
 be
> in force for INactive MBs, the map supplied by the commands will be in=

> force for active MBs.  There will be compatibility aliases to
> `minibuffer-inactive-mode', etc.
>=20
> I think this will enable you to solve the problems you have.
>=20
> It will likely take me a few more days actually to implement this.
>=20
> [ .... ]
>=20
> > Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
> > Computer Science Department
> > University of Maryland, College Park
> > E-mail: styang@HIDDEN <mailto:styang%40fastmail.com>
> > E-mail (old but still used): yangsheng6810@HIDDEN <mailto:yangshe=
ng6810%40gmail.com>
>=20
> --=20
> Alan Mackenzie (Nuremberg, Germany).
>=20

Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: styang@HIDDEN
E-mail (old but still used): yangsheng6810@HIDDEN


--05f223638e384f30bb46cbec1eacd7de
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>Thanks for the =
quick response! The changes sound good to me.<br></div><div><br></div><d=
iv>On Mon, Apr 12, 2021, at 05:18, Alan Mackenzie wrote:<br></div><block=
quote type=3D"cite" id=3D"qt" style=3D""><div>Hello, Sheng.<br></div><di=
v><br></div><div>On Fri, Apr 09, 2021 at 03:57:01 -0500, Sheng Yang wrot=
e:<br></div><div>&gt; Any update/decision on this? The discussions have =
been inactive for more than 2 weeks.<br></div><div><br></div><div>Sorry,=
 I got distracted by another project which turned out to be bigger<br></=
div><div>than expected.<br></div><div><br></div><div>I will decide this,=
 basically to follow Drew's suggestion, since he is<br></div><div>the on=
ly one with strong views on the subject.&nbsp; What's more, I am now<br>=
</div><div>convinced he is right.&nbsp; ;-)<br></div><div><br></div><div=
>To sum up, the minibuffer will always be in `minibuffer-mode', regardle=
ss<br></div><div>of whether it is active or inactive.&nbsp; The minibuff=
er-mode key map will be<br></div><div>in force for INactive MBs, the map=
 supplied by the commands will be in<br></div><div>force for active MBs.=
&nbsp; There will be compatibility aliases to<br></div><div>`minibuffer-=
inactive-mode', etc.<br></div><div><br></div><div>I think this will enab=
le you to solve the problems you have.<br></div><div><br></div><div>It w=
ill likely take me a few more days actually to implement this.<br></div>=
<div><br></div><div>[ .... ]<br></div><div><br></div><div>&gt; Sheng Yan=
g(=E6=9D=A8=E5=9C=A3), PhD<br></div><div>&gt; Computer Science Departmen=
t<br></div><div>&gt; University of Maryland, College Park<br></div><div>=
&gt; E-mail:&nbsp;<a href=3D"mailto:styang%40fastmail.com">styang@fastma=
il.com</a><br></div><div>&gt; E-mail (old but still used):&nbsp;<a href=3D=
"mailto:yangsheng6810%40gmail.com">yangsheng6810@HIDDEN</a><br></div>=
<div><br></div><div>--&nbsp;<br></div><div>Alan Mackenzie (Nuremberg, Ge=
rmany).<br></div><div><br></div></blockquote><div><br></div><div id=3D"s=
ig97546008"><div class=3D"signature">Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD=
<br></div><div class=3D"signature">Computer Science Department<br></div>=
<div class=3D"signature">University of Maryland, College Park<br></div><=
div class=3D"signature">E-mail: <a href=3D"mailto:styang@HIDDEN">s=
tyang@HIDDEN</a><br></div><div class=3D"signature">E-mail (old but=
 still used): <a href=3D"mailto:yangsheng6810@HIDDEN">yangsheng6810@g=
mail.com</a><br></div><div class=3D"signature"><br></div></div><div><br>=
</div></body></html>
--05f223638e384f30bb46cbec1eacd7de--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 10:18:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 12 06:18:26 2021
Received: from localhost ([127.0.0.1]:56576 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lVteE-00009n-0L
	for submit <at> debbugs.gnu.org; Mon, 12 Apr 2021 06:18:26 -0400
Received: from colin.muc.de ([193.149.48.1]:16033 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lVteB-00009Y-72
 for 47150 <at> debbugs.gnu.org; Mon, 12 Apr 2021 06:18:23 -0400
Received: (qmail 75255 invoked by uid 3782); 12 Apr 2021 10:18:16 -0000
Received: from acm.muc.de (p4fe15ca4.dip0.t-ipconnect.de [79.225.92.164])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 12 Apr 2021 12:18:16 +0200
Received: (qmail 6728 invoked by uid 1000); 12 Apr 2021 10:18:15 -0000
Date: Mon, 12 Apr 2021 10:18:15 +0000
To: Sheng Yang <styang@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <YHQeZ6DhP5uiWu8Q@ACM>
References: <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
 <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Sheng.

On Fri, Apr 09, 2021 at 03:57:01 -0500, Sheng Yang wrote:
> Any update/decision on this? The discussions have been inactive for more than 2 weeks.

Sorry, I got distracted by another project which turned out to be bigger
than expected.

I will decide this, basically to follow Drew's suggestion, since he is
the only one with strong views on the subject.  What's more, I am now
convinced he is right.  ;-)

To sum up, the minibuffer will always be in `minibuffer-mode', regardless
of whether it is active or inactive.  The minibuffer-mode key map will be
in force for INactive MBs, the map supplied by the commands will be in
force for active MBs.  There will be compatibility aliases to
`minibuffer-inactive-mode', etc.

I think this will enable you to solve the problems you have.

It will likely take me a few more days actually to implement this.

[ .... ]

> Sheng Yang(杨圣), PhD
> Computer Science Department
> University of Maryland, College Park
> E-mail: styang@HIDDEN
> E-mail (old but still used): yangsheng6810@HIDDEN

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 9 Apr 2021 08:57:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 09 04:57:30 2021
Received: from localhost ([127.0.0.1]:49060 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lUmxF-0003Xk-Nq
	for submit <at> debbugs.gnu.org; Fri, 09 Apr 2021 04:57:30 -0400
Received: from out1-smtp.messagingengine.com ([66.111.4.25]:46857)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <styang@HIDDEN>) id 1lUmxD-0003XV-NM
 for 47150 <at> debbugs.gnu.org; Fri, 09 Apr 2021 04:57:28 -0400
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
 by mailout.nyi.internal (Postfix) with ESMTP id 5B08A5C0103;
 Fri,  9 Apr 2021 04:57:22 -0400 (EDT)
Received: from imap2 ([10.202.2.52])
 by compute6.internal (MEProxy); Fri, 09 Apr 2021 04:57:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
 mime-version:message-id:in-reply-to:references:date:from:to:cc
 :subject:content-type; s=fm2; bh=MObfWssnmqdoxFT+3UhQ/0TlJvBziHo
 LIBtY/6Tuon4=; b=HKpgG1pHVshOWNTFMHGYWSqrFMFdx8xBDN21+VSjdZLS7eV
 qAAcG1MOngt0XadUzzOv8lqE47CPaNvMXq6VOtS3pwJhy1pJ/4Z3kNWjKC+8wDIo
 LPWzTziHaidnPQZYg3wLUMvUEVqHYYlPMs4bqjx6ZW3Tj1nmw8Dm372Sd2pxIkoz
 SAQDLaGrxsWsXtHeejH2lZu1jJJbB5N0WYtRmpAcwD0LcjqxSBIW336g3C2kkUGf
 E+UIy5vutj/kkHdvOBAH7uDmMF/RJ6r12xqIs6XEV8X5plNGAZzokkG6Jf62jYsO
 NPiCr4Yw8vOW/Dg/ZFDHdNi32VlAjVIFPd4QAlg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=MObfWs
 snmqdoxFT+3UhQ/0TlJvBziHoLIBtY/6Tuon4=; b=k3Yqy/Gp9/cje+THeT8gau
 lT6DcVJ6D2AIRnxD0ua/tqF9P1f3HmbEcotdclFk7RgbyUtiV6SeoBg3LJtMbg/U
 Pxr9avSaakQi3IQg/AP86tm0n2UnEFuOQwQPwMFfZi5C78PB3WF+1xhN2OCsUTB5
 36s1yAyegH4nOlrsr8vwJCqpLgnFr2O9DovHQy9u2+jaunsq7vc8anbBSJYcrHr/
 Q+48s+udFzmYy+hJ6SjhfDXHb1kQlzfKKZr00LUyidajd4PGHiXmFLBsJn5sAWu4
 OhoeSerHOKFLAFt+izElhPu9yq1hGKneKpCCKET7ZZomejNjWgszN7a4+jh2NfnQ
 ==
X-ME-Sender: <xms:8RZwYENa-D6Ku4o9JF1QTl2AVjfNU_QPdMaleXJdSgo2g8NSS67N7A>
 <xme:8RZwYK-8kIgsr67Ht3B-NZAp5o5Ce2pxfV0b-Hug7OcNJUIrYkdCVsd8gk6l3jB0n
 cS8ChM_NPq-19lH7MA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekuddguddtucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfuhhgv
 nhhgucgjrghnghdfuceoshhthigrnhhgsehfrghsthhmrghilhdrtghomheqnecuggftrf
 grthhtvghrnhepheeluedtudffffegffeileettedvudeihefhvefgvdeivddttdeifeei
 geegveejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh
 epshhthigrnhhgsehfrghsthhmrghilhdrtghomh
X-ME-Proxy: <xmx:8RZwYLTo2dmArQk7AabFcaDPY4yoGEo14XO-XevpR5JcqFwPBX1__g>
 <xmx:8RZwYMs4rWs-E3zUOb-jqLi9VglVRtHXzEJE_CGtrkf97jER9kpbpQ>
 <xmx:8RZwYMdULxvwW8mlqKUtJMN5QLLe06DkzvZKVsLHKaoRu1mpFTnR4w>
 <xmx:8hZwYIFySN0yUSxy3sFYmKr8h4iO3xmN5zXaojnYst2bsoxlnIrobA>
Received: by mailuser.nyi.internal (Postfix, from userid 501)
 id B787DA00079; Fri,  9 Apr 2021 04:57:21 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249
Mime-Version: 1.0
Message-Id: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@HIDDEN>
In-Reply-To: <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
Date: Fri, 09 Apr 2021 03:57:01 -0500
From: "Sheng Yang" <styang@HIDDEN>
To: "Drew Adams" <drew.adams@HIDDEN>,
 "Stefan Monnier" <monnier@HIDDEN>
Subject: =?UTF-8?Q?Re:_[External]_:_bug#47150:_28.0.50;
 _Incorrect_major-mode_in_m?= =?UTF-8?Q?inibuffer?=
Content-Type: multipart/alternative; boundary=fe3f80cbb0984c43b668191968bd1984
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Any update/decision on this? The discussions have been
 inactive
 for more than 2 weeks. On Mon, Mar 22, 2021, at 16:36, Drew Adams wrote:
 > > > 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 >
 [...] Content analysis details:   (1.1 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [66.111.4.25 listed in list.dnswl.org]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (styang[at]fastmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [66.111.4.25 listed in wl.mailspike.net]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 0.8 FROM_FMBLA_NEWDOM28    From domain was registered in last 14-28
 days 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 1.0 FREEMAIL_REPLY         From and body contain different freemails
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Alan Mackenzie <acm@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

--fe3f80cbb0984c43b668191968bd1984
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

Any update/decision on this? The discussions have been inactive for more=
 than 2 weeks.

On Mon, Mar 22, 2021, at 16:36, Drew Adams wrote:
> > > Can I ask what's wrong with what I suggested: One mode, not two; j=
ust
> > > change the name and provide a helpful doc-string that covers both
> > > active and inactive?
> >=20
> > What's the benefit?  Have you tried to implement it?
>=20
> Is there really something to "implement"?
>=20
> Rename `minibuffer-inactive-mode' to something
> without "inactive".
>=20
> Give it a doc string that says when inactive...
> and when active....  We already have the former
> part.  The latter can just point out the keymaps
> (which become links to their doc).
>=20
> Benefit: Like what we have now - or after Alan's
> change to fundamental-mode - but with better doc
> and without a misleading mode name.
>=20
> The behavior is already there, no?  When inactive
> we get the inactive key bindings.  Otherwise, we
> get the usual minibuffer keymaps.
>=20
> IIUC, that's the case whether or not the "active"
> state nominally uses `fundamental-mode', since the
> minibuffer keymaps are still used.  The difference
> is (1) doc and (2) only one mode.
>=20
> Feel free to let me know what I'm missing.
>=20

Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: styang@HIDDEN
E-mail (old but still used): yangsheng6810@HIDDEN


--fe3f80cbb0984c43b668191968bd1984
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>Any update/deci=
sion on this? The discussions have been inactive for more than 2 weeks.<=
br></div><div><br></div><div>On Mon, Mar 22, 2021, at 16:36, Drew Adams =
wrote:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt;=
 &gt; Can I ask what's wrong with what I suggested: One mode, not two; j=
ust<br></div><div>&gt; &gt; change the name and provide a helpful doc-st=
ring that covers both<br></div><div>&gt; &gt; active and inactive?<br></=
div><div>&gt;&nbsp;<br></div><div>&gt; What's the benefit?&nbsp; Have yo=
u tried to implement it?<br></div><div><br></div><div>Is there really so=
mething to "implement"?<br></div><div><br></div><div>Rename `minibuffer-=
inactive-mode' to something<br></div><div>without "inactive".<br></div><=
div><br></div><div>Give it a doc string that says when inactive...<br></=
div><div>and when active....&nbsp; We already have the former<br></div><=
div>part.&nbsp; The latter can just point out the keymaps<br></div><div>=
(which become links to their doc).<br></div><div><br></div><div>Benefit:=
 Like what we have now - or after Alan's<br></div><div>change to fundame=
ntal-mode - but with better doc<br></div><div>and without a misleading m=
ode name.<br></div><div><br></div><div>The behavior is already there, no=
?&nbsp; When inactive<br></div><div>we get the inactive key bindings.&nb=
sp; Otherwise, we<br></div><div>get the usual minibuffer keymaps.<br></d=
iv><div><br></div><div>IIUC, that's the case whether or not the "active"=
<br></div><div>state nominally uses `fundamental-mode', since the<br></d=
iv><div>minibuffer keymaps are still used.&nbsp; The difference<br></div=
><div>is (1) doc and (2) only one mode.<br></div><div><br></div><div>Fee=
l free to let me know what I'm missing.<br></div><div><br></div></blockq=
uote><div><br></div><div id=3D"sig97546008"><div class=3D"signature">She=
ng Yang(=E6=9D=A8=E5=9C=A3), PhD<br></div><div class=3D"signature">Compu=
ter Science Department<br></div><div class=3D"signature">University of M=
aryland, College Park<br></div><div class=3D"signature">E-mail: <a href=3D=
"mailto:styang@HIDDEN">styang@HIDDEN</a><br></div><div class=
=3D"signature">E-mail (old but still used): <a href=3D"mailto:yangsheng6=
810@HIDDEN">yangsheng6810@HIDDEN</a><br></div><div class=3D"signat=
ure"><br></div></div><div><br></div></body></html>
--fe3f80cbb0984c43b668191968bd1984--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 23 Mar 2021 15:45:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 23 11:45:12 2021
Received: from localhost ([127.0.0.1]:32787 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOjDQ-0002GO-0n
	for submit <at> debbugs.gnu.org; Tue, 23 Mar 2021 11:45:12 -0400
Received: from userp2120.oracle.com ([156.151.31.85]:44008)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lOjDJ-0002FY-JI
 for 47150 <at> debbugs.gnu.org; Tue, 23 Mar 2021 11:45:06 -0400
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12NFi7Ku094811;
 Tue, 23 Mar 2021 15:44:52 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=p4wEvmEBk/0N8Pjs8T//KauHjeYn63vnwEgMkd8pdPo=;
 b=gASop0lA7kPDTTmh9UPV5E8IKJHq5MNXiUlLtcjWCEozk2jcptApDDnGqV10ifjpScSK
 RmhSUfd1x/WqyDPt03dD7uvAyCXQUZFy69I0Hno4r+dCGqANA9NJOh+/4xEQUVArLtm/
 u+eIeYzsAy1c0C45AbTTX4bhWAPn74GIUb31ymyU87AgFA1k7+HrPrIUcQdL6k711cpD
 jbOisjsXEYVS50p6O/Ek0SO8G/Vk++0XcC9n6m9AdhiOp5mKhhvXahaqFKdrVbUcbyuw
 vPrW8w0BxQcqd0weZYYLvIFNSQK6px06Mltl6hzS+/ah7PcZSu6LrdahYDP0juX0QMdw Tg== 
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79])
 by userp2120.oracle.com with ESMTP id 37d9pmyh8w-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 23 Mar 2021 15:44:52 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1])
 by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12NFeArv099961;
 Tue, 23 Mar 2021 15:44:51 GMT
Received: from nam04-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam08lp2047.outbound.protection.outlook.com [104.47.73.47])
 by userp3020.oracle.com with ESMTP id 37dtts3u9b-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 23 Mar 2021 15:44:51 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=fsnLFT5M2MSePutyd1VHcOPO+0zPw6tvbyY/GYqv5SHQxzg5NhYypW9cN6w/lVbsYHVgRMjydu1rsl6wynrUbkZmq3OZZNz5nCJbmN1k9X54e3C7LGNDy18cRuO1pClWk923J6uhuOjzoAhnzWyqIjgkzjKQCO+I6TDJxVq9GtvkzXAj/sbUhS3BpDNh/GJdwnu85zUa2mckLDoZ+jm61idV92B6sgHKRc0IqzjRYCRzpoXsZ/RCA/L43rkb0eN7t9j56MlctqtmCeXNnNBR6uP7aIImahUQcoAPu1t8ZrtOFPloE+Zl8wL6z20cBih9YEq6PGFRO+pUOUnOhOzTHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=p4wEvmEBk/0N8Pjs8T//KauHjeYn63vnwEgMkd8pdPo=;
 b=VbsWqZNa81rGtdLpt4s+fijJyhqb2mGxlvY4mV2TpZAPrMcYcULcE2jWWp/xyfea1jjjONZ9eTcYEThil5r5Vz1GT6MqSssdLn7LWE3ZnFLSGVieUMa+WtjBy9HysQ50Qt02U8HrEqmWDHN9iWdZ+s4fr6lLZFWJEjRXRpFPLhfkiYBe7HEebRpDmFEnyqi0NIiG1551URYRlo9hvjUq2vsjQgxikQUqaWJEiEAJjKmeccZIr86tfbvGKKpqNv9o74Hif/EfyjnPNnUrCxRDAgWQQ9REqPDrwMm+WbQ5Eee5QtIJM+idw3tb4LqfhnCcTqXkHNl2SG96bCZbDeYndg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=p4wEvmEBk/0N8Pjs8T//KauHjeYn63vnwEgMkd8pdPo=;
 b=XA3OSmjmRuQFTdqJJ6LgUdCIq83IWrO2KBVR1gqE5dTeVyyc9/+0BlBulvke7SgF5evusW+piBIxuNjxnrzAi382Bm8UtShBHgsg6JMRXkclIVPHwyCJgfBLdBspvBFuzGQ4ynCd/sEZ0ic67dRq9FWzv0+haDR0zN9UcIdO7+4=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SN6PR10MB2797.namprd10.prod.outlook.com (2603:10b6:805:cb::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.23; Tue, 23 Mar
 2021 15:44:47 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3977.024; Tue, 23 Mar 2021
 15:44:47 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Index: AQHXH+U3Mfqrx+LstUi6bwxoL5CE4aqRtJLg
Date: Tue, 23 Mar 2021 15:44:47 +0000
Message-ID: <SA2PR10MB4474C8FDEF88C29DA15B13E8F3649@HIDDEN>
References: <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
 <YFiz0mFjJt6ePXUb@ACM>
 <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
 <YFjFcr15EUyNmRh0@ACM>
 <SA2PR10MB4474EFA866F722642F468CF3F3659@HIDDEN>
 <YFkS0Q1MKm3sEyrT@ACM>
 <SA2PR10MB44741648B052D1BB76F9F8B7F3659@HIDDEN>
 <YFnnmfATiO9QU4xP@ACM>
In-Reply-To: <YFnnmfATiO9QU4xP@ACM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: muc.de; dkim=none (message not signed)
 header.d=none;muc.de; dmarc=none action=none header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f2cb073f-c049-4b61-f41c-08d8ee129646
x-ms-traffictypediagnostic: SN6PR10MB2797:
x-microsoft-antispam-prvs: <SN6PR10MB27973DE83E81D4F74E41A99BF3649@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: sGZxfiXqniucKrfP9udwfO6YlvxandOivX0viDiVWonEHx1yoGpDz197zvF+NTK4jGkZP20hbqYCXo20EtDMjjrG86eP9S5Cxn1T/D0gOCKpYIQI6iMVEsxpRAyCDEUPVYMhvv5mU+Sp34NLbnZ59Ik/NfuMgnsmeKQF/SwPBHjJ189xtdeCF9KMIqzjcOPKUjhqNwSF2gdfy17U45+I0o71VBhYY2sF4X5gyRNzBKYxMoq9HxpjjOVcg+G9tPulw8W1PE3/jTPjMMZTnWgneGjosokQ0hEhr3mrIzNFWkZG5rx7OT0nFRG3tKgI7Si4IbVVBPB/u0WtpQ8HsJffDt9sRMVq4cSmplX2ZTDWS7I/UY5m5bP/ZvzWiwNxoW7NvxHUcy17ksOlRep7taYrIL+4RonRT1M+vOD6TEha9REZZdMcRuNKZEW8fxlcKaP0HmjdaJmGDwwrzKdhl/2+l5Wu1o+zwzOjRoEXYhgGidAvqgJV6qYsAmCcl3Z4702Th1u2TXjCJXXoQZlbt9ULUDwXn/QziCGC5zdJM0FwaziSfm9qu3WNW7P2DWWwTWIFoZdgJfqLue7crLTxGw3RpcuhPsuqgSp/RitPWOZK227BhqA9maX3chKpjpgyyaxov+M+c/uwikPidXaRz0GGDg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(376002)(396003)(346002)(136003)(366004)(39850400004)(66556008)(5660300002)(33656002)(6506007)(86362001)(66446008)(26005)(38100700001)(66476007)(9686003)(44832011)(8676002)(6916009)(64756008)(66946007)(478600001)(316002)(4744005)(2906002)(55016002)(76116006)(71200400001)(4326008)(186003)(7696005)(8936002)(52536014);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?AbQSFcAzt0rT1zVAS0bVXQt8F7FKvbUKShdtHcM/2Ql8BkNhZHdUklTWe5Rv?=
 =?us-ascii?Q?glYOr/nV4tP0EK6pRLtZxblNMomGDHgvYpdfThysFpdTZeEoIq4vkfheFpRF?=
 =?us-ascii?Q?pmFeQrGEMSiiOSVFkyqWaZIOc22fB+nRQhn1cfgVA1PFLcIq0hI7Ac8bNqeF?=
 =?us-ascii?Q?ClMr9ARJXHhMVoX1Oh41Hj9ULlJsqXTd1jsRk20RC/I5b0v9NGEC9OUq2cCc?=
 =?us-ascii?Q?8WweUjowNyRlAvI5W3vdR97UmqI2HuhnjyDzNtpdZKDjRuZNM2CLLrq2hz4P?=
 =?us-ascii?Q?762opgvA/6ENU1NKZJXrbXIQrxjHyyF+6bdS9hZBGjElKaqOtGHlHkhYk+hr?=
 =?us-ascii?Q?YAXaz2iV0pelRjpTdwGnUk9qZyfQVj4xg9SB0c4nFdfkOfR+S0g0tmZNFXxM?=
 =?us-ascii?Q?l7UFyknfZ7NAxP2c2T36XLG+JW2t6ISKM41R+0VjnxjVL9LNMCe5xxQ+CMDV?=
 =?us-ascii?Q?bzLyo4Go7C5hJm2MLk+VCPnrQx494zQ51ebmnfjnNx/8Iy41i+BWSme0xCAi?=
 =?us-ascii?Q?q99UT9IP10bSCjjN/1UO22Q8kZjG44JeRzYNy7HDKGHD4jlmrojhaObm5e+Q?=
 =?us-ascii?Q?E/yxKVTb89Q6t4ZXm52bOjLeB2eeD5s/Z0URxsgGlbHCmE0yj29zhDAZSpfP?=
 =?us-ascii?Q?R9crRCf4GxfnSSvbah5CiQTy+zzrUzQNze9P6LbkevVIV8nK1joDsyph2rzX?=
 =?us-ascii?Q?5JN9U/YWFKOs512/0Pc76S/jVPZEEdciv3kIJfcACsBFT6QSz+24yGYtR42s?=
 =?us-ascii?Q?tbEYkiB2tLjDM34B22OyOepq+An86VbpAIx9wUsev0Xt/687LJlfwc8lxB4a?=
 =?us-ascii?Q?+uyXAspAiN81zZYodpijh2Co4fgB+bFVQUHS5TCmb/4InE4iBxpDE2BPr8oo?=
 =?us-ascii?Q?wSN5ZpxCzRDZkNcebuqMkWhvbr9zwc/GCmIcNwtMhkRYt/82DqM4o+lxODxZ?=
 =?us-ascii?Q?hE3ccWVNucoRckMpHUstTReEYnv5LxqxlaAlJKhx1Dp1agSTlc4eP1DDxF6n?=
 =?us-ascii?Q?ngtG84PmuyBqhp9Y3CrUdcmKbN2YazjbXfpL8ErjEDcq6tcJVurTUyUyIcIf?=
 =?us-ascii?Q?qv4CQBqutwIuva5wmK8x+ccr5jnaV2jO8vqhKa+sYOXvI64csN882KVR+0lX?=
 =?us-ascii?Q?YyKdyIBcLe5lC3bzpBL+amQDmMEBSNMIWbxpDTNHUncmfwe/gws5v6z33QnD?=
 =?us-ascii?Q?VkqODHw1n0XUiU0dL4GTzAitKkc2SH3w57E5MIX6xaPF1sQIhegqwnAd7VQM?=
 =?us-ascii?Q?CmLXHCQI3TxgMB9W/X+mNN90h0XXMF0KWslAhtMRBLWundd717FdQY39KYm7?=
 =?us-ascii?Q?CcyXEZcI60/zo2mnmuPOZynp?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f2cb073f-c049-4b61-f41c-08d8ee129646
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2021 15:44:47.0332 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: N3xPKQ1l8ZKnz2weenXlHL4ofJ6hWwiC7IpmymRnlifSKraJqX/cnCiw3j+ms7A6zuUTLjrrsDjMeP1hvegTAg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2797
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9932
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 malwarescore=0 spamscore=0
 mlxscore=0 phishscore=0 suspectscore=0 mlxlogscore=816 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103230115
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9932
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 lowpriorityscore=0 phishscore=0
 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0
 adultscore=0 clxscore=1015 malwarescore=0 mlxscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103230115
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Thanks to all for clarifying things for me.
And thanks for considering my suggestion to
have a single mode, whether or not it makes
sense overall.

I trust you will work out a good way to handle
things.  I hope whatever changes are made won't
negatively affect my use of Emacs (and I expect
they won't).
___


[Other changes that were made after Emacs 26.3
mean that Emacs 27.1 is completely unusable for
me with my setup.  I haven't been able to track
down just what the culprits are.  That's a big
problem for me, and it probably adds to my
wariness of changes to minibuffer behavior.]




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 23 Mar 2021 13:05:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 23 09:05:40 2021
Received: from localhost ([127.0.0.1]:59834 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOgj5-0004It-Qg
	for submit <at> debbugs.gnu.org; Tue, 23 Mar 2021 09:05:40 -0400
Received: from colin.muc.de ([193.149.48.1]:54829 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lOgj3-0004Id-CN
 for 47150 <at> debbugs.gnu.org; Tue, 23 Mar 2021 09:05:38 -0400
Received: (qmail 86922 invoked by uid 3782); 23 Mar 2021 13:05:30 -0000
Received: from acm.muc.de (p4fe159d5.dip0.t-ipconnect.de [79.225.89.213])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Tue, 23 Mar 2021 14:05:30 +0100
Received: (qmail 6715 invoked by uid 1000); 23 Mar 2021 13:05:29 -0000
Date: Tue, 23 Mar 2021 13:05:29 +0000
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <YFnnmfATiO9QU4xP@ACM>
References: <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
 <YFiz0mFjJt6ePXUb@ACM>
 <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
 <YFjFcr15EUyNmRh0@ACM>
 <SA2PR10MB4474EFA866F722642F468CF3F3659@HIDDEN>
 <YFkS0Q1MKm3sEyrT@ACM>
 <SA2PR10MB44741648B052D1BB76F9F8B7F3659@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <SA2PR10MB44741648B052D1BB76F9F8B7F3659@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>, acm@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 23 Mar 2021 07:18:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 23 03:18:48 2021
Received: from localhost ([127.0.0.1]:59416 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lObJQ-00087N-8O
	for submit <at> debbugs.gnu.org; Tue, 23 Mar 2021 03:18:48 -0400
Received: from chiru.no ([142.4.209.132]:33796)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jakanakaevangeli@HIDDEN>) id 1lObJO-00087D-05
 for 47150 <at> debbugs.gnu.org; Tue, 23 Mar 2021 03:18:46 -0400
Received: from localhost (unknown [178.172.46.206])
 by chiru.no (Postfix) with ESMTPSA id C249612801AE;
 Tue, 23 Mar 2021 07:18:44 +0000 (UTC)
From: jakanakaevangeli@HIDDEN
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: bug#47150: [External] : Re: bug#47150: 28.0.50; Incorrect
 major-mode in minibuffer
Date: Tue, 23 Mar 2021 08:18:45 +0100
In-Reply-To: Drew Adams's message of "Mon, 22 Mar 2021 18:38:54 +0000 (11
 hours, 50 minutes, 9 seconds ago)"
Message-ID: <87lfaes5gq.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

>>> 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.
>> 
>> 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)?
> 
> I didn't think so.  My impression has been that
> the mode remains `minibuffer-inactive-mode'.

>> [...]
>> 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.
> 
> Currently, the minibuffer is (I think) _always_ in
> `minibuffer-inactive-mode'.  Its mode hook only ever
> kicks in when a minibuffer buffer is created.

True, the mode doesn't normally switch to a different mode in 27.1, but
on the other hand, the function `minibuffer-inactive-mode' does indeed
get called on every minibuffer entry and exit (except for the first one,
I think) and its hook gets run every time.

The only thing Alan changed recently (for 28.1) was to instead call
`fundamental-mode' on minibuffer entry and now wants to change this to
call `minibuffer-mode'. As I see it, this is as small of a change as it
can get.

>>> 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).
> 
> Should we have a different major mode for each kind
> of active behavior - completing-read, read-file-name,
> read-buffer, read-number, read-expression,...
> 
> All of those behaviors are different - different
> key binding.  By your reasoning we should have
> different major modes for them, no?

I believe Stefan actually proposed something like that in a previous
message from this thread when he said read-from-minibuffer could accept
a major-mode/functionp argument. This would allow for straight-forward
documentation of each different minibuffer usage in `C-h m', including
mentioning the ability to use general editing commands.

Besides, wouldn't it be cool to have syntax highlighting in `M-:'?
I believe function eshell-command already does something like this, it
puts the minibuffer into eshell-mode.

Not to say that this comes without its own problems. For example, if a
user binds current-local-map's RET key from a major mode's hook, he will
not be able able to use RET to exit from a minibuffer in such a major
mode. `eshell-command' works around this with a minor mode that binds C-g
and RET to appropriate minibuffer commands but this solution isn't ideal
in my opinion because the user's modifications to minibuffer-local-map
aren't taken into account.

Perhaps a better way to make a major mode for use in minibuffers is to
derive it from an ordinary major mode and use an :after-hook to install
a local keymap that is composed of minibuffer-local[-completion|-ns]-map
and the current local map.

> [...]
>
> Do we even know whether adding that major mode to their
> lists would solve their problem?
> 
>> I'm not familiar with any of the three packages cited
>> by the OP,
> 
> Nor am I.
> 
>> but in previous discussions, we'd already been through
>> talking about using `minibufferp'.
> 
> Dunno what that was about.  See previous: the minibuffer
> has a major mode, `minibuffer-inactive-mode', doesn't it?
> Why is that harder to handle than some other major mode?

See above. Alan recently changed active minibuffers' major mode from
`minibuffer-inactive-mode' to `fundamental-mode'.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 23:06:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 19:06:38 2021
Received: from localhost ([127.0.0.1]:59102 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOTd8-0000Fv-2P
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 19:06:38 -0400
Received: from aserp2120.oracle.com ([141.146.126.78]:56454)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lOTd5-0000Fh-Lf
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 19:06:36 -0400
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MN5j1c014692;
 Mon, 22 Mar 2021 23:06:25 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=;
 b=pVGICRBhRr6LALefniSbHxP488uJcYeFv4ignKNtGdQvUoK4qHZkfSiZ4sfjlF4IyybE
 CgDAHb4LjF1hZJQ3n+uf0tBMNtWLLP0ZxCZb7IkaCS8k9y/O0rsBDbUuJCHK9CpKzIWF
 zIxM44+oh8PJMtHuIVJ08MoYqQNQKZopFEwF552YSLrl9dq5Vwx2cq/xqyS3bwbwF+0j
 XP8lsuwAekQgArS3YOrkHaiM5qs/WtaQzqiCd1InivFk+Sf4qcVGTBRhQMb2AAtfL/kS
 LBC17f0jlkduzlXqWtqDeydmfVpccsXaHQqOMiglmUJYOlJjISnFpO785NilIFbjc7w5 cQ== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by aserp2120.oracle.com with ESMTP id 37d90md37k-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 23:06:25 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MN54Z7196254;
 Mon, 22 Mar 2021 23:06:25 GMT
Received: from nam12-mw2-obe.outbound.protection.outlook.com
 (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41])
 by aserp3030.oracle.com with ESMTP id 37dtmnseuq-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 23:06:25 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=amFjXF2P2ZLDcWi3EZ3svz1+NVnSatZk81Z7CNQMNlxl0cabepctCMmqiB4y1xg1TMj3rdO/XoeS8d1o91+MYlb0gdx+ZlzhBOCHiU77SUu2cFj5WUFhzJRSPwo3+QEkje7KsnHItrIRAU9w18GOOFa6G0t1A1GzMao1h5F4E15AOAbeJgyq05RWazx7NKMeYhe/yJgFiIEnY0ecfZxNSygbW5F/7FLmtBhvXVxCuIYrTY2iQCiTJj5HK6GjaQRtBnXRHen18yCUgrneTpVvWEksEfgFvZ8MMO4YH4UVxy0SymB+fh3Wuriay9DBQyPh7ZbENWliR3DDhq5bT27J+A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=;
 b=FahqCc0KbdfkNkeyBsKvwt6QqNIBQyzI9G1fv26KdhIa4QOy1jMs6b6DhmwYWIV6vXUQHhnG8yWKpdgy3P8H3fD15m/pggSOYNHeNJGhs2oCsApUDERjuaOYTNIb0ogFx2nVVk6m90j/rKMaML9lwlKaOYDej+of9nDVfX2gjIUMFDPA/pHttShwslK1QrrE4P9gtY1gnIBS61K11KQ98Q0QndD0TsdfCEep/kzyvl0jYNZumd+U+qVY/rXeWIKumo7hGFeJnMMuaRq19vWebXtcbHNG0YnpdFIWh2YnMVL0XnUmG2Afpfu2x+tyI1VHrMPXRCX5ttZGySKIQFHCNw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=;
 b=Yd5+y1clGY4XHzRH9OvbxwWB78rdkf6H+smzeA5wDVQiQ9zV1JSc7JrCfVFk3loR4OSLMEqJ9Bz4Hz8D0IiJKcZgfAtSiMYtDc2bYeL+Z3haQ82VWn9ct1H+hqsJCtlkgKUDrQDLW46+E9fC0Q9C9FIFWjUWOe6+TenqU7su9js=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4649.namprd10.prod.outlook.com (2603:10b6:806:119::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar
 2021 23:06:23 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021
 23:06:23 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Index: AQHXH2ZkGbJ696fBvEOoaQW9Kej3KKqQmMdg
Date: Mon, 22 Mar 2021 23:06:23 +0000
Message-ID: <SA2PR10MB44741648B052D1BB76F9F8B7F3659@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
 <YFiz0mFjJt6ePXUb@ACM>
 <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
 <YFjFcr15EUyNmRh0@ACM>
 <SA2PR10MB4474EFA866F722642F468CF3F3659@HIDDEN>
 <YFkS0Q1MKm3sEyrT@ACM>
In-Reply-To: <YFkS0Q1MKm3sEyrT@ACM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: muc.de; dkim=none (message not signed)
 header.d=none;muc.de; dmarc=none action=none header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a7758aef-9275-4d64-bec6-08d8ed871cd0
x-ms-traffictypediagnostic: SA2PR10MB4649:
x-microsoft-antispam-prvs: <SA2PR10MB46491815D431774D1EBC45DCF3659@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: u1/pqbjoUibxpkiMxlZfmsN24S1h73OO0ht71PLW+nIZd4gpUP7f3lLpKB+FXpbbCrsPKHj7pbFEVlLENlbouZVGI6t0ugGHF0qjCqjRD3fSFL5vzCHbUpUJU/hb6LYq/nvElWVwkjZXtQEwhbOL9zwl++2wFjUAB8OxzwbIvJm7sITUQpSy0WYFde6gw4HkSYwBUjq9aFqKPkt+LKNcOUvtlKMBTz/meOZmyPQ0hdqvngtPVhdruvQtNJNMxrqz83LtXthrerGTrN96DkY3vas7ZhhASJIWLZFrEhjnswa/fcQFkS8TPRTDTiO0aZS0gMBR/I5U3kN2lifLix8V2Gy0uV8MFmboEEVK97PX6CopXJhgIcud0KNi6MW96RtpqvRVa8vKrzdtHzOTJH0icAvmuHsv0V5hUaz/cKL0d/eO8jiTU2h/ACdp0eHlyB6lBKuJbXZr5xKmfCSvtu05K5n+amRPzAh8rZsAxYWeq2oeAPPesMLGSXjmCOhBa94NvkMNlTHdi6jLKSyB+4H+SMtGaCQg2sXYVgjECoElSPXq0lDcjuOUDvpa1VxQLzyW1mfC+moU4lp2kKqqMqhJy/Gpswb40oywXXG3faZEOuPu/ZyfOEGRWPiPRpbGzEedTikB+rHNbRyjYWEp6ZLmHPJRqjmZsi0MS+6HoISjA7c=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(346002)(376002)(396003)(39860400002)(136003)(366004)(71200400001)(76116006)(6506007)(6916009)(5660300002)(66476007)(86362001)(478600001)(66946007)(316002)(26005)(66446008)(66556008)(2906002)(186003)(64756008)(9686003)(7696005)(55016002)(33656002)(4326008)(38100700001)(8676002)(44832011)(83380400001)(8936002)(52536014);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?9M4kU8wocriba3Ee4bfQrfN7uloBIzpckWCoHm6HU5GmQrJmOhKbdH2FUGfG?=
 =?us-ascii?Q?3RUMPSiHHTtepKxyyNSDtIptNUJifBMbVYCXMSRpzzuVBECN+jVZrq7+E4vv?=
 =?us-ascii?Q?Mi9V8RXQT87gf1APYi7yIVxtZhe/IkssiboDBWAlunGDd4IQAG6PZXfJVGeI?=
 =?us-ascii?Q?HMyPMIlonJRsg3g+F7FdBXfBwtHsYTFlWD+SWwixE04ICq8hsRyoDMCQpWQ9?=
 =?us-ascii?Q?ZZRLtPxvVcjR6W4EExW8xD56GsW/mSJnrJqnvKSqfX/eB148e6KM3ILKpLkc?=
 =?us-ascii?Q?Z9IBBGj4maaUyXJCQ+1YtW7NTnjeBkKUg6xmtdMwNUn3vZE5SkoLrYtCNN3r?=
 =?us-ascii?Q?94TWIqmc2Zca0IcmpTy/i54WpTsssvYQ6CK9gXNZhJYqgM7Bc1qtqDrg7dTJ?=
 =?us-ascii?Q?6G+JkCGng4Cy5VrCnpZ0XPjfw8ibkhtPhbZOw9E1Pw1Rdck+BMxImAhVeG9P?=
 =?us-ascii?Q?xDfvWHUh8Dg6J84pjgmbVNYdlGbjHHh/YXWQqaI3037YzPqvzs4SKOEtsp8h?=
 =?us-ascii?Q?7r7udGEmfuhxB5VVTwoSq73bFVqfVOF9JEijcuytsc7NYOT4Yrl0NitaOpxR?=
 =?us-ascii?Q?pn+LhtyiknvCXQqx69pLANM1AFFRSobkg+e6v4ASIQcFPUYrxdODnmjEA8zy?=
 =?us-ascii?Q?T7pKL5+2eZbMQMhjq1roU99q3bqvpg3sZr9fPlOWwWKL8LVC/87uoCkswJ+t?=
 =?us-ascii?Q?L/FQF+XCOCH2CX1MsEqOzdL/KwTLk0xB4NGlV17wDSD2rS3ZTk7D66aS4Gt8?=
 =?us-ascii?Q?WMiAhjjZ+CPPoGQIhkTXDcbQq5MCj46KNat/UhLbPnGDPqBD6wA4L8VlxV4F?=
 =?us-ascii?Q?JC30JQJk+72u6Mk4GmlbC7D5TL03Uc1Ws++lVQ+vTYlNvwzJGgTX2jO47zq3?=
 =?us-ascii?Q?Y0sz+bxleC1veCo5WQb+ghloB0d6yfGVRJL0vyK4TzgyQDuV5rnnFZT+23ns?=
 =?us-ascii?Q?wX06ZVxTD6oi0yCdWCZJQmgqF50DhuQnAxNGtbEBuColukIXmahLCPlRAIPQ?=
 =?us-ascii?Q?fcV+dAwFmSkSh22lelNhfCfuL4Wbqxe4WvGi4HBS1OdKGD+3ZG0qtFf/Pu3m?=
 =?us-ascii?Q?FiFrxiFABTPnU97feo67dsoEdYf2+UkX6YwCxanIA2QPJ3DwhifFERu0aEuq?=
 =?us-ascii?Q?qC8yNnall1shrfQXZBNhvQcIYseeFe3Akd2PVTj14RFoojv9+B2RxvN4xXLZ?=
 =?us-ascii?Q?YXnfKoHUg7qvIfJCTP1BaJplcVryIh4y+PR56Mn2rZaBQ7L30w+3IhEcvzZb?=
 =?us-ascii?Q?+A7OK9GpqKOfEIarhV/KezXBLLSBqSfHBdmjVsQmPOkjNNtSeRiXMKg0IPYq?=
 =?us-ascii?Q?nq7bIFPf1s/ugsQN2TZuouPX?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a7758aef-9275-4d64-bec6-08d8ed871cd0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 23:06:23.1988 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: k70f6E2RcWycb0sZI8XOZHJCdazpfs38U7pcMLezmvcCdrs+lXJYa7shZ/MiwdrXvUe/q2wy5Z9wbvmbosRtIA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4649
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxscore=0 phishscore=0
 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220171
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 malwarescore=0 mlxscore=0
 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0
 phishscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220171
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> > > However, on being reused, these buffers remained in
> > > minibuffer-inactive-mode rather than being restored to fundamental-mo=
de.
> > > This is silly, and "obviously" a bug.  I fixed this bug by making an
> > > active minibuffer always be in fundamental-mode.
>=20
> > I don't see why it's "silly" or "'obviously' a bug", sorry.
>=20
> It's silly, because the mode is called "...-inactive-..." and the
> minibuffers were, at the time, active.  It was obviously a bug, because
> the major mode was different the first time the MB was used, from the
> subsequent times.

OK, silly mode name; agreed.
But how was the major mode different?
It remained `...inactive...', no?

Yes, it became actually active, but the mode
stayed `minibuffer-inactive-mode', right?

Is there something more going on than a poorly
named mode?

> > Yeah, I see that the doc string for `minibuffer-inactive-mode'
> > suggests that it's not used when the minibuffer is active.
>=20
> > 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.
>=20
> 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)?

I didn't think so.  My impression has been that
the mode remains `minibuffer-inactive-mode'.

I said that the behavior is "effectively" as if
that mode isn't in effect - its doc description
doesn't apply when the minibuffer is active.
But the mode is still `minibuffer-inactive-mode'
- or so I've thought.

> > 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.
>=20
> 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).

Should we have a different major mode for each kind
of active behavior - completing-read, read-file-name,
read-buffer, read-number, read-expression,...

All of those behaviors are different - different
key binding.  By your reasoning we should have
different major modes for them, no?

> > `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.
>=20
> > 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.
>=20
> > > An active minibuffer doesn't use its own key map -
> > > it uses the key map supplied to it by the calling function.
>=20
> > Exactly.  Exactly.  Exactly.
>=20
> > An active minibuffer doesn't have a separate mode from
> > `minibuffer-inactive-mode' (a misnomer, when active).
>=20
> > And functions dynamically provide different keymaps
> > for different active-minibuffer contexts/uses.
>=20
> > > This is how being in minibuffer-inactive-mode (which
> > > does have its own key map) "worked" for so long.
>=20
> > Yes.  It just means that `minibuffer-inactive-mode'
> > is a do-nothing when the minibuffer is active.
>=20
> > 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.
>=20
> > (At least it _should_ be useless.  And it will be ...
> > until someone decides that for "consistency" or
> > "completeness" its keymap should really take effect.)
>=20
> 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.

Currently, the minibuffer is (I think) _always_ in
`minibuffer-inactive-mode'.  Its mode hook only ever
kicks in when a minibuffer buffer is created.

OK, that does happen occasionally, for recursive
minibuffers.  But I think worrying about its mode
hook is fruitless and needless.

> > 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)?
>=20
> To quote the OP:
>=20
> >>>> 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.

> > 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.
>=20
> It's entirely credible that these packages use lists of major modes, and
> that their use in an active minibuffer is appropriate.

Sure, I get that (although it's abstract).  But can't
they just either special-case the minibuffer mode or
explicitly include it in their lists:
`minibuffer-inactive-mode'?

Do we even know whether adding that major mode to their
lists would solve their problem?

> I'm not familiar with any of the three packages cited
> by the OP,

Nor am I.

> but in previous discussions, we'd already been through
> talking about using `minibufferp'.

Dunno what that was about.  See previous: the minibuffer
has a major mode, `minibuffer-inactive-mode', doesn't it?
Why is that harder to handle than some other major mode?

> > > This isn't really the sort of bug that has recipes.
> > That, right there, hints of a non-bug, I think.
>=20
> That somebody is unable to configure a minor mode like
> she used to do...

Sorry, hold on.  Like she used to do?  So something was
changed?  Do you mean used to before Stefan gave the
minibuffer the major mode `minibuffer-inactive-mode'?
That was a while back.  Did that cause a regression for
the OP?

> 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.

As for "using it for active MBs" - there's nothing to
change (IIUC): that misnamed mode is already used for
active (and inactive) MBs (IIUC).

It's just that the behavior of the minibuffer changes,
depending on whether it's active and, if so, keymap is
used for the reading.

> > 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.

But I admit to a poor understanding of the problem.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 21:57:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 17:57:47 2021
Received: from localhost ([127.0.0.1]:59046 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOSYV-0004ny-E6
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 17:57:47 -0400
Received: from colin.muc.de ([193.149.48.1]:32027 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lOSYT-0004nk-AV
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 17:57:46 -0400
Received: (qmail 62438 invoked by uid 3782); 22 Mar 2021 21:57:38 -0000
Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 22 Mar 2021 22:57:38 +0100
Received: (qmail 9173 invoked by uid 1000); 22 Mar 2021 21:57:37 -0000
Date: Mon, 22 Mar 2021 21:57:37 +0000
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <YFkS0Q1MKm3sEyrT@ACM>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
 <YFiz0mFjJt6ePXUb@ACM>
 <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
 <YFjFcr15EUyNmRh0@ACM>
 <SA2PR10MB4474EFA866F722642F468CF3F3659@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <SA2PR10MB4474EFA866F722642F468CF3F3659@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Drew.

On Mon, Mar 22, 2021 at 17:09:32 +0000, Drew Adams wrote:
> > Things are already broken, slightly.

> I don't see that you say how things are (even slightly) broken.

I think I meant that with regard to the philosophy "if it isn't broken,
don't fix it", in that I had already fixed it, so a further fix in the
vicinity wouldn't do any further damage.

> > 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.

It's silly, because the mode is called "...-inactive-..." and the
minibuffers were, at the time, active.  It was obviously a bug, because
the major mode was different the first time the MB was used, from the
subsequent times.

> 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.

I haven't checked whether its mode hook gets run, but I think it would
(if anybody put any functions on it).

> 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?

Because of the negative effect reported by Sheng Yang, the OP.

> 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.

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.

> `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.)

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 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)?

To quote the OP:

>>>> Packages depend on it [the major mode], to name a few: lispy,
>>>> smartparens, and telega.

> > 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.

It's entirely credible that these packages use lists of major modes, and
that their use in an active minibuffer is appropriate.  I'm not familiar
with any of the three packages cited by the OP, but in previous
discussions, we'd already been through talking about using `minibufferp'.

> 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.

That somebody is unable to configure a minor mode like she used to do
doesn't feel like a non-bug to me.  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.

> It sounds like a misunderstanding, to me.

On whose part?

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 21:37:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 17:37:03 2021
Received: from localhost ([127.0.0.1]:59034 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOSER-0004KE-EK
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 17:37:03 -0400
Received: from userp2130.oracle.com ([156.151.31.86]:38088)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lOSEQ-0004Jk-1c
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 17:37:02 -0400
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1])
 by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MLPjFR109454;
 Mon, 22 Mar 2021 21:36:56 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=n40kbV84LltyLEd7l16+4NBeBkM1AooPY/CXiQSiMJE=;
 b=Fgt24YrX2dJx5Ojbd9NsF7Wo6ktJZNeyIVaTNYR7dTIMnvLhKG72ppec2XCiT5jD0nV7
 Etfgf6To4nO0T5doubVdxEBjSh89+8gKq0isekaE1ISFdb0M/xdNKCeXOpwnImXex04l
 ekOsLT1EOtJgQ370Ocqu5Rx0V8mGCPYSNN/0/64YloSDodnH3CVPoTo9QjZH1UKtMZEN
 jCPBpMa3njXr6i74n8Nstnr1jcMvvzke90vE9ZlUagNtT/JVZdvkmy/qYpNDR622aP3X
 Zt3RpEVZ6axhpT4f+jqrwLAeqJhrk/o0LpeBkIeRZKpNqUZdcxmWy33cqV7H62938zAW hw== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2130.oracle.com with ESMTP id 37d8fr4xnd-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 21:36:55 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MLKrsW127589;
 Mon, 22 Mar 2021 21:36:55 GMT
Received: from nam12-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam12lp2177.outbound.protection.outlook.com [104.47.59.177])
 by userp3030.oracle.com with ESMTP id 37dtywkyqg-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 21:36:55 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=buiuc5ichw9iqcOiVHe1Sz08W+xAQ/r8jI8Kdmzceq56tR8zcmZ8gSgilXhLIzh2xsYBUR96aZutoddvZmmdxcdCv+afSj+bVY0QWvEG+JaOIyE+ybiu52jHSVLyOffVILEC9/mRGhaqAsC1Uyk+JJ4zngEZ7tNJ3dzrwsJl1IR1gwZFRdpX7v1dFSPQWfZJyf3updN9HR7cKlaX47QM8HXGJdjuceO/QJtv2tRx3KQfONhiRdPmImIjU62jnxk8cqgzO3J6oIbI+jRL7uFEG8NDYr5aaS8PujqWdOZ3GgNQr0kqhH69ruxCj7EnFLdGrFC8G8ulLGYBjlN3JP9jIA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=n40kbV84LltyLEd7l16+4NBeBkM1AooPY/CXiQSiMJE=;
 b=gv9elsmbMvhwLSIMYz7RL0hdc5D5C0DudHCB5Ngoi7ioHNTRLaEN/4K7b5GoDXVK24nr8+6LIJhyDnEy79mXGr6iG4sSkmS1yz1G0RFySOKfDhXD0Y0Xa5YQRBBfd2n+kmjH+T34EZikFjAG55HDx5AHwJDjIbNaFtlZuqlMsmHRBJ6/9dQNZ4ibRquQJCzT59XAmQFBrkyoLX4chja4sCx1NR5a8ZPyKusxI8ElcinTAGtscygjWbfGd58PCg4OvF7/gbkpBcsNFSAizVspGjxwJ22zGIOYU0Jrpsf5Dlyry2eivDzqkZi4Zkt7tY60A01SV4xFdEUgJsYGZ34OVA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=n40kbV84LltyLEd7l16+4NBeBkM1AooPY/CXiQSiMJE=;
 b=Z+XQA8lFCzVi/iH23hkj+DcLsMLQOHVO7xcgKWQdmvNTgAQHrj4qRNQOJXvihiXY6WqxZ1GfrsHgNDHAXIzqMDVnPON7BvkqisqUQo0kkhIUNAroloE2OdxOA36SCgT0cogxDy/I9lHV8U9OLjvTdd6qpNdIoLPhZVgEJJxfmxg=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4780.namprd10.prod.outlook.com (2603:10b6:806:118::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar
 2021 21:36:53 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021
 21:36:53 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Index: AQHXH1eL2/hwyGfNj0aZBjqNTMDLa6qQhpbA
Date: Mon, 22 Mar 2021 21:36:53 +0000
Message-ID: <SA2PR10MB44743FFB0B94C635596D907FF3659@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iro.umontreal.ca; dkim=none (message not signed)
 header.d=none;iro.umontreal.ca; dmarc=none action=none
 header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9e38bd72-4405-411a-3c0e-08d8ed7a9c55
x-ms-traffictypediagnostic: SA2PR10MB4780:
x-microsoft-antispam-prvs: <SA2PR10MB4780A75ED46A36751EEA81FDF3659@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 58GqkddjWWxCzotU5FxadOp2455anC7CtlxTNV5ZukDRBxX9mGFepFtIpvd1nGzhfn1rrS/X76aqlJcMKPqzYpM3LntAlfGh0tBe6X3bAgPtTLCw2x8fU2kd7l2NoKpszmgzrkd/yrutFr0erUU/TJf3eYC6+GFTv5tE6X+433ZgutVxaj19A6TrVWpi3puosM/EzRkgOZjWA5gEEOd2PSMrYuAyAUfBC3/ZVVQUrkccQljBmb+ovmbOQKsgzowD05ZPcp16KSVDDzq4ke9eGolBAHMpsBboouciXcS10guxhQ7QGyFH/Z2mRGjZS8BYq1Vr00gkcXDMS7Gl7J2zJL1K0RpS3dE4BQPUsSR0UWs9wgfVEAkmu4+2MnGxedbm9YgeYh289mzrVFUqyVCjcEuxjI6RCwAJdtaISS2t5GNry/9wuyLBDaQyKktLBsF0HftNBsQnYao4M8UYfGzBhL93X5MElKrJkByQgD4NTPgxbg5pi4iGa3h7vSnHxleESnBXfxxfiCrteYq4U+bgwIKaKaywvc9+NRfMi+YsyCqlOvYKbm4vFpAW2iv4jv16Bn1wrvlcMvJvTzxXCAlJoUXEcuflZAemcR8A1ohosbFFDHTTpCIQfq1mlMFp1O9mrqrLIrPpnT3wb7keOaV/s7iITShBOWRPLLuQ1/etTVA=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(39860400002)(136003)(376002)(346002)(396003)(366004)(9686003)(71200400001)(55016002)(4326008)(86362001)(8676002)(2906002)(33656002)(38100700001)(76116006)(186003)(54906003)(296002)(6916009)(316002)(26005)(66446008)(8936002)(64756008)(44832011)(478600001)(66556008)(6506007)(66476007)(66946007)(7696005)(5660300002)(52536014);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?sqHnBn81krT9M1+4A41tB5B+u8dfVhn63UiC2cH+tSMmzLuclv/+uDhVyJMo?=
 =?us-ascii?Q?KTQaa8KjQgAi+ZcFKCxTa9CeJOTicCJocbrswZewsHGAF8bTFtdfRMwRWYwf?=
 =?us-ascii?Q?FetFWHLBbVeaNf5MM3w8sU8092osL4uMapCW3pgYo6JbGuaznB/8Gee/bUYR?=
 =?us-ascii?Q?o9s+rdKQFma/2WlpEUzRZgcZlNyw6/dXtjUuHqwq2Q1Q1rQS90iTHI5pbdzb?=
 =?us-ascii?Q?Hl3AOlwV0kHGaOuScMEVS9qGL06Ytz4CN10jRUURvfjaSaJXK7UBI/ag5RI/?=
 =?us-ascii?Q?7QfzRQSDVv4rTbLl2xg13IKMtTEU334i9/UC0CrainwmFHtaMFdPXTW8A9V/?=
 =?us-ascii?Q?FtgcZ3gB8ExRcSKb44MlvR+eFk4f//fNhpyTZ5QQDpXSUrqJIgZtgqzo/cdt?=
 =?us-ascii?Q?Dti/UA3uXXLKsyV95JoBcmLbszsHJw1dwjhaZUOoG9KGaRrCmnkRq0+SR2W4?=
 =?us-ascii?Q?It2TFQQp8/iJ5BmlPZhPeZ6E+3EIT+10yEL6C1wI7J/vgAhycyVjH8BMiA7h?=
 =?us-ascii?Q?g4cOyNU5T1+dlScPnWpXyuOFRddPDWhYHb1b96j+a/SKm9bZKOMiyQgZxJK9?=
 =?us-ascii?Q?GlT9CYuqAMh9UADZ3X2TfxBOPXAHxwEsA07DzBFEwfg4PYbXj7S41PdZnASh?=
 =?us-ascii?Q?aw1LHmdHn4UhfxlmH6+rOF/kJC7ZMfHnIwdsdayR7z14tS+8ZO/rZB1Tg/IX?=
 =?us-ascii?Q?x3+mVEAlkI+JwQ2OJMy3FJgwvcQggoZFP88Z9r2iPudkLrRCVEWrZnLfkox9?=
 =?us-ascii?Q?ZSLoY2tiuGybcj24nO7qJkU8k93mgW3VhVpENQc6Gm7XK6xHsFdPIR6HBfg7?=
 =?us-ascii?Q?w+D1UrQcXkYosWVid33RVxSjiXwSYdaked6u6+8H6zW6WBghmwDgA785JAsy?=
 =?us-ascii?Q?9P8yPKkGLITdyoCa/KHk0x+I7RAaHSjw2msyTnAjdCQrDVEMW1zSbFgAmBOU?=
 =?us-ascii?Q?/wWbWly6+TkBiv2VAdFDBAr4RI3C/dBWmlhK81ctF5VVP2pi03vcmjurNIfW?=
 =?us-ascii?Q?sRryuy5/LixvwHOMJyxuacfFLRoVFdIV6g3nLuSfy2FVk+pOqsZ96cg9NUnm?=
 =?us-ascii?Q?t7cPA4H4rLQZsUziO7UAL2LTpWPUyEtIX4CZi1jxwWxXED69bkra1qEUOFiT?=
 =?us-ascii?Q?v0a6MGecl3ndG78zJCEMoQBeOXH3azQ145tOwpVy6s6Y9ygVmWf76VHjvnT6?=
 =?us-ascii?Q?Rji+9w2hniud+NbABdZWccWwNGBAdFXOW0M4zfP8w4sPez3TyGzpCASMSVXt?=
 =?us-ascii?Q?cWA0bA3gWgsz7J+dAEiIGcWCpOktwdbYuxX4v8XGgqiuWzJtzlsrfGF/vYtj?=
 =?us-ascii?Q?6ASM4indWivHICKZitNLzTL4?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e38bd72-4405-411a-3c0e-08d8ed7a9c55
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 21:36:53.6295 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CDxRSCG9kVPzFflfHXRakgxlY4pKk7IzheCdV0YIA0xMXx5Gsr/s4nmbxjixDjYcLpTPaExZy0uG6Y6mFhbK9g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4780
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 phishscore=0
 mlxlogscore=803 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220157
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 lowpriorityscore=0 priorityscore=1501
 impostorscore=0 spamscore=0 mlxscore=0 suspectscore=0 mlxlogscore=999
 phishscore=0 bulkscore=0 adultscore=0 malwarescore=0 clxscore=1015
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220157
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Alan Mackenzie <acm@HIDDEN>, Sheng Yang <styang@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> > 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?
>=20
> What's the benefit?  Have you tried to implement it?

Is there really something to "implement"?

Rename `minibuffer-inactive-mode' to something
without "inactive".

Give it a doc string that says when inactive...
and when active....  We already have the former
part.  The latter can just point out the keymaps
(which become links to their doc).

Benefit: Like what we have now - or after Alan's
change to fundamental-mode - but with better doc
and without a misleading mode name.

The behavior is already there, no?  When inactive
we get the inactive key bindings.  Otherwise, we
get the usual minibuffer keymaps.

IIUC, that's the case whether or not the "active"
state nominally uses `fundamental-mode', since the
minibuffer keymaps are still used.  The difference
is (1) doc and (2) only one mode.

Feel free to let me know what I'm missing.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 20:11:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 16:11:29 2021
Received: from localhost ([127.0.0.1]:58911 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOQtd-00009l-1b
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 16:11:29 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42559)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lOQtb-00009P-Ns
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 16:11:28 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 568F3100236;
 Mon, 22 Mar 2021 16:11:22 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 88DEF100225;
 Mon, 22 Mar 2021 16:11:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1616443880;
 bh=wRgtCkFQYVIrG5DnU272X4rNRVtkAMr4TA5SJZJ2hTI=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=TuQlTzR0WFB1cabZd8uBcs62j/0OcSkI34lLc/vIjR00taoHQaR6mlVQfvFtyy0eM
 McabnFgYh+Ky2ppdvz2OiOl5YkEauYNcMb5ZgodkL0dqlD5QAXDj7Kt8fTqSfjCIuT
 a1QdTgqWYcSedTJ1XEuYET3SvhXaANcIPgMcd54DROTbhB0YeL9VNU9mHgn7WVk75o
 gaLSD82fBNESGUHiT0A3QUfxNU5CtN5Gk/9mqE8ilxcOlyF6I1L33lRRHGfE6Ma+c8
 /gpByrbZEFdo/1dt5G0GTXsH9PIIwKII+CqEe56N+6usD8ebXqpphDb2Pe+hzL4bt/
 CPUmO5+Fru6Lg==
Received: from alfajor (unknown [216.154.43.249])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3D2A912021E;
 Mon, 22 Mar 2021 16:11:20 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <jwvft0noszu.fsf-monnier+emacs@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
Date: Mon, 22 Mar 2021 16:11:19 -0400
In-Reply-To: <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
 (Drew Adams's message of "Mon, 22 Mar 2021 19:42:21 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.099 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Alan Mackenzie <acm@HIDDEN>, Sheng Yang <styang@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> 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.

Those problems have mostly been fixed indirectly by the introduction of
`minibuffer-inactive-mode`, which happened to kill the local variables
at the end of an activation.

Before that (i.e. in Emacs<24) there were cases where
`indent-line-function` was "inherited" from one minibuffer to the next.

The remaining problems (that is, until Alan fixed it by re-instating
fundamental-mode upon activation of a minibuffer) were those of an active
minibuffer inheriting the settings from `minibuffer-inactive-mode`.

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

I don't think this should affect users either way (except indirectly by
the likelihood of lingering corner case bugs).

> 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?

What's the benefit?  Have you tried to implement it?


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 20:03:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 16:03:56 2021
Received: from localhost ([127.0.0.1]:58795 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOQmK-0008JV-0H
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 16:03:56 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7574)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lOQmI-0008JH-LJ
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 16:03:55 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0BED310022E;
 Mon, 22 Mar 2021 16:03:49 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BB583100091;
 Mon, 22 Mar 2021 16:03:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1616443427;
 bh=JRZjUQjhfy6RE2JJQ5B6BnjbWzMOH0cZVtEtI5RsySE=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=GzP5cZ+1A7FCd51qh8cotjwjNU5reLUnHZI3RicunddW+24JH3qOlIJ1Nl07YMWFx
 XBfjEXfHrGVCJ/Ms9XAYzudM6+LkAIlSj1X7Wr8b3AJOHhscjlXRBUGZmyEbpe2bWs
 IM5tO+u14f4zlv0xuOM3i4R+uE9W8AwjH/AAORRgaZHwlZBR+RGiOiJnrH+gruZYdR
 ZTzbuhiYx5+KI/T/l47s5+5PPSeCGZw3mdCylomUTcfLb4dZcTRFfB5O+Of5TZNh8E
 cVi2uZwtjlweO2rgDSy27EknaaTg4TEhhogz6BogRvqXDTy8jIV14yKwKZzW8xiFQH
 6WsZ4Crapn5Ig==
Received: from alfajor (unknown [216.154.43.249])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8AA8412040D;
 Mon, 22 Mar 2021 16:03:47 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Message-ID: <jwvlfafot3r.fsf-monnier+emacs@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <YFjzEnyB9G6jESyX@ACM>
Date: Mon, 22 Mar 2021 16:03:46 -0400
In-Reply-To: <YFjzEnyB9G6jESyX@ACM> (Alan Mackenzie's message of "Mon, 22 Mar
 2021 19:42:10 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.099 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org, Sheng Yang <styang@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> The minibuffer used to be "always" in fundamental mode in Emacs<24
>> (since there was no `minibuffer-inactive-mode` back then), so I'm not
>> too worried.
> As you agreed earlier, I think we should put minibuffer-mode in place
> for those minor modes which maintain lists of valid (for them) major
> modes, and suchlike.

Yes, I indeed agree.  In the above I was just pointing out that changing
the name of the major-mode used in the minibuffer shouldn't be
a significant source of problems, since it has already changed in
Emacs-24 (and that didn't elicit much reaction, if any).


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 19:42:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 15:42:32 2021
Received: from localhost ([127.0.0.1]:58727 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOQRc-0007jw-9d
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 15:42:32 -0400
Received: from userp2120.oracle.com ([156.151.31.85]:42398)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lOQRa-0007jh-8w
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 15:42:30 -0400
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MJe15l079232;
 Mon, 22 Mar 2021 19:42:24 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=ICL9shq9Q7wS86XuUHeb3KiaCytyuQQUWxu8naKY2uc=;
 b=dSlPaUAhDtHJWMeDqp18JnIrRgBJSAediGn21ggd70QqO7T/OxVWR10HlahXtMGmQwd5
 8/4tRI7S5lcfCkG7TTZVhsoo+d/RSM7ChQR0SV1nVGplRO1uBuX/c5ceBewRar9A5gSi
 puY/bh1phz9QKWlGsLRPKXgnLRU/sDXqK/e5WjL1/bYnMEy2MLm56lJU5z7Czhbsj8IE
 16WiaEw1INRo+FcdhUN8YWpS24NQGiDAjMABeZXrZiKN7eVHLqEqDS6eKVJjgNQWZ8uv
 6Mz7L+hQo0LSxcNGtI61KRgHMMYKuXxDC2v4IGfeWh+Ro6UMB/egxpL+CSqmP7pKc1UJ xg== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2120.oracle.com with ESMTP id 37d9pmvm4q-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 19:42:24 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MJeboe193415;
 Mon, 22 Mar 2021 19:42:23 GMT
Received: from nam11-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam11lp2169.outbound.protection.outlook.com [104.47.57.169])
 by userp3030.oracle.com with ESMTP id 37dtywgpb9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 19:42:23 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=UqCTV1sDiNr+SlSN2d726JfjBOal2bqjLIqdauuC4GgTkwWATnoAC+0n0tsSvAhaV6u0RMtF2vwfOGsSI0nFUDe8bvowdQJIf8ylX3Eq1jn0s/0E+Rswzx3LBObtzyf2zumnc/Bo050mm9rqjhGu9YvqSQ+Hlgbtt03ypT3cv7WyBsbHUTSMgF1246bF9Cc8VxFXiscp6TcbhtmPYvHiSz17//49n1dOM4277MZIFyXViHfx30+R3DKKrv0IshyyrPs7Bl4h7swi267C3AjxBGtFP6UsSi2+tkgnNXy+cxDfTeWCc3hJhz6KxfVdya9hdzeLCkqjKw6VcDj/OIDLRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ICL9shq9Q7wS86XuUHeb3KiaCytyuQQUWxu8naKY2uc=;
 b=d3+0IzB7y5/PNl7ANw3IN7+fHgTKJR3j2htzWhD/7FR5dWiPpU8KBsgb+ayP+oP5DXNfTE5hC+1eHFaiMH5I1wuBIB0qLvYOiB7wzIx1zTC6JehTWxaEBVtoR9eQ5LK/etz7MGVij9KY25lZ7quOGeuXV11j3XlQeF9DG4pbSt/qIlaQthx3yGnw3SQNDxYs1gaArShByk20+0y8ZW2ohtUKX1swJ/65NkhPaS7Q+gFsY9GgQ7tq3NUuuh+ojOcaWwBCywtBQlvGK3s/IbBstlV/FVwFYo0dW5cIGUPG4FvkZu4gTMYGIAIxyrgCHwXUk+nwWin6i7DuOSfMqZxVhQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ICL9shq9Q7wS86XuUHeb3KiaCytyuQQUWxu8naKY2uc=;
 b=obPQ57k8C4clat2V1DoxBufVTXqZXIPjhWIETOx9fi3nnzg48gw3Q7jMRJIM5pQDxUrWhyl8IjKCEFOMkP6Tu++S8mLwKWamXsLBOvJAQjgRjPC1XxoB5USlIklI8QDD2L7CDEkpTHrSFg1Ac0tW4vYZIzmqfUClkTJpjbMIAUU=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4634.namprd10.prod.outlook.com (2603:10b6:806:114::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar
 2021 19:42:22 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021
 19:42:22 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Index: AQHXH1HkSy92TZ2uh02eoEgOCtiSq6qQZhQQ
Date: Mon, 22 Mar 2021 19:42:21 +0000
Message-ID: <SA2PR10MB4474021932E9256272B85951F3659@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iro.umontreal.ca; dkim=none (message not signed)
 header.d=none;iro.umontreal.ca; dmarc=none action=none
 header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3fd825fd-c94c-40eb-99ab-08d8ed6a9c79
x-ms-traffictypediagnostic: SA2PR10MB4634:
x-microsoft-antispam-prvs: <SA2PR10MB4634FFDCB013E99B99301732F3659@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LJpcGpoMXuufd4sg8M3+F8smNpHa6BSKq6c2r8DXSj32nw5qswD1ihpZl4XBHNMTd9tu20goAB9BqiXA0kx5tK9FQBdvIfcZmbl6OWu7d6bqobIbjYPDEb2vGY/JjjnXErIGK+2uqor/WWgTyANJUFogKcRCSamw1DLV3RZUaQjo4oBBZwZPoq9c2/w1n5I/0LHr1izsiLpARJLaqpIcOR8z63+b/pdCg9uYfUHuAz7nnnemFuicewxCU/dAdyM3i716C+DLN9+ZIqHfMHeSORb9QOfdxn4bOJbrtMcdt7jQBQtU6PcW0Haa/QZiTn/QZrf+vMzzFsNFCWl8cocP9m14N+/b+vgCwp6yFyViPoLJZ5CiMn29FOI7n1G/xkjkzCgaxRogVHySxtMBkWPG1fstcmSM5pQR7KqTDPePXDw5gIEYfAGwgOq7y+nw/M4qcJ2Oxd5gMb0Dm02WW3l43RZV84wrUJcqlc1yOPBIQew93glZxjepvFHp7RTv+kRzsN15+ktXylW7XKhVWXuolnF38071C87RRX8bSzc6j677NoF91UcFwybFrkto/0UlZ3XPjCgXV4TTV6r79nO5dNnekk2h+sj4MjV75nOqAfNH628Yi+/Ud3JuBdgwgpksMoCdEjWMjiI/oFV1vP1qqeFGcamh1IJvaoquVg9y+YY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(366004)(39860400002)(346002)(376002)(136003)(396003)(6916009)(54906003)(66946007)(5660300002)(8936002)(66556008)(6506007)(66476007)(26005)(186003)(7696005)(66446008)(83380400001)(76116006)(478600001)(296002)(44832011)(52536014)(316002)(64756008)(33656002)(4326008)(9686003)(38100700001)(71200400001)(55016002)(2906002)(86362001)(8676002);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?9DIzWyOjiojOIO4eliklcMAnk/oax6Nc5W6evxGU2NlxrLk+34uXUeBl5Uzm?=
 =?us-ascii?Q?a5/zbfvWRif/wZ2a+27UwJ8hqJpfdnV2GSgKOCaGCd1MST0ymD9mLlikJrM5?=
 =?us-ascii?Q?p/2/w4hRAx1s2Q7Fk/OTE2fJ2Q2lRhy234kyniMaRzcl3rzJEz+YzS7LYM97?=
 =?us-ascii?Q?ikMY6talufOQea6opJHzqlEK/nhLBwxejzPx6EvEGE43Jq3BNO9Lgld6a6ZN?=
 =?us-ascii?Q?wZu8jNSRWU7Djk2w/gAs1LHHy4kuo7SzHbzm6L2MTm1n49UwEuKKZP+0OTaL?=
 =?us-ascii?Q?hxEEgkJGfa2Zci1adv70XoMnTxEQZCeFC8wfCPtxBo9TZf/AEWqAes4DoVeu?=
 =?us-ascii?Q?cw3VmXiRUs+2u/oOTFqiN5PR+zvQ1avBpzg7HLAt5W58sbJ19Jikhcv+8rcS?=
 =?us-ascii?Q?wzZ1GOlPcZhjfAu55uYuW9RXwhaIcSi3c0SPF/D/PGluj5I7TxoJURdShi8A?=
 =?us-ascii?Q?uQ9e7+QuhykjtOTeoY1OST/5Dd6MSWJT1BqqMRt17ef+k8uzmyotghNgflM+?=
 =?us-ascii?Q?dAuD/eri/drMCYyZVdVeg2rFx+KqzFrYYRSj5MndyHqIB7ZKscFJGY/FPcXk?=
 =?us-ascii?Q?HW9TrzTxxhxdGvKt/Zl3rIZqUwW/muHugmPe45elhAUrRZ4TdU4JqIQnP5f8?=
 =?us-ascii?Q?zh0SEsM5JjROKazE/A8ORSpDK4wvpXiChAkwRfxiDQ31Zxu5NhIS+qjcmTVS?=
 =?us-ascii?Q?0ORedSYNN3bDqlONAzoMh+VlYlbw3RZ+AE0XWIZaY3NJrOXcm83wmqyq9grc?=
 =?us-ascii?Q?Ft1SBYLTs8X8dRbncTEkWO707fm+JblAhw3Vv07MiJ0RiNCgcd3MOgmWygzI?=
 =?us-ascii?Q?PhpvH+7O4KI5ByPkrj1AI7/NPUVPQfwU5k/w2NKKbSOUw9ZIm8XVdSNKqoe2?=
 =?us-ascii?Q?6f3bbyktHIFt/hNuSsgIzg5itxAILllUWuHzvzIcaLV+z+A8BfOst3M5ItPk?=
 =?us-ascii?Q?AXfhn1U2Tse0F533/kiOrorsCNLc7qqDiE/fRwSb5RiaBx9qPaMmgDZgg//+?=
 =?us-ascii?Q?SqR87+2yWPnUQpSnRR5arDSBjmFOXlelDg2ldVK4MWrECX1dOa8JocpVlQwq?=
 =?us-ascii?Q?FjQwXP7d48VY6nWX3+CGZMx/mki4mwF/Vm++oax1U1DKDzt0YXnY8wfgpNxx?=
 =?us-ascii?Q?KvStGO2iy+VuMkQXqYA4GopSq2eQrwX5DRtGYdcqL3GJEY6I7dr9DjI9dBTH?=
 =?us-ascii?Q?MgV7eHRemOymMSWTnsfJoR01lEq0UYlR9TSdKH1AUjkZwku207e22dF8PrHX?=
 =?us-ascii?Q?38mpqmdZP/7GchDFWXK4oA9wr+DciHmWTTPvxCEZ+y2g4E3oBbqxnRAdtY2G?=
 =?us-ascii?Q?sjYiVRmr/K4jNrIwntlSC4Xh?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3fd825fd-c94c-40eb-99ab-08d8ed6a9c79
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 19:42:21.9829 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zWyQLsIAfgw1+YjvGHLmmLCWyuoaRwDH3Xj7kbC6ZAWgb7LzdJpCHjKAsBSAtOkOBr32crSy3QdcYJDlCcDUSQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4634
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 phishscore=0
 mlxlogscore=999 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220144
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 lowpriorityscore=0 phishscore=0
 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0
 adultscore=0 clxscore=1015 malwarescore=0 mlxscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220144
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Alan Mackenzie <acm@HIDDEN>, Sheng Yang <styang@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> >> I'm in favor of introducing a `minibuffer-mode`.
> > Why?
>=20
> 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).
>=20
> >> Part of the question is also when and how that mode is activated (sinc=
e
> >> 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?
>=20
> So a minibuffer isn't affected by what happened in its previous invocatio=
n.

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?
>=20
> Why not.  That's already what `eval-expression` does, except it does it
> piecemeal instead of via the well known major-mode concept.
>=20
> > What's involved, besides keymaps?
>=20
> 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?
>=20
> 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?
>=20
> 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.)
>=20
> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 19:42:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 15:42:19 2021
Received: from localhost ([127.0.0.1]:58723 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOQRO-0007jV-VB
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 15:42:19 -0400
Received: from colin.muc.de ([193.149.48.1]:28519 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lOQRN-0007jC-OO
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 15:42:18 -0400
Received: (qmail 74161 invoked by uid 3782); 22 Mar 2021 19:42:10 -0000
Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 22 Mar 2021 20:42:10 +0100
Received: (qmail 8616 invoked by uid 1000); 22 Mar 2021 19:42:10 -0000
Date: Mon, 22 Mar 2021 19:42:10 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Message-ID: <YFjzEnyB9G6jESyX@ACM>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org, Sheng Yang <styang@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Mon, Mar 22, 2021 at 14:08:46 -0400, Stefan Monnier wrote:
> [ Hi, perpetrator of `minibuffer-inactive-mode` speaking.  ]

:-)

> > minibuffer-inactive-mode: the critical thing here is "inactive", which
> > means "doing nothing", or "not in use", or even "sleeping".  The
> > opposite word is "active".  From its name, this major mode was never
> > intended for use in active minibuffers,

> That's right.

> > but somehow nobody noticed that the buffer never got shifted out of
> > minibuffer-inactive-mode when it came to be used again.

> I did notice, but it didn't seem to cause any harm and I didn't want to
> get into the discussion in which we are now, so I left things as
> they stood.

Umm.  Maybe I should apologise, then.  ;-)

> > I've been fixing things in minibuf.c recently, and when I discovered
> > this anomaly, I fixed it, so that an active minibuffer now runs in
> > fundamental-mode, as originally intended.  I did wonder why there was no
> > "minibuffer-mode".  But it was clear from the code that whoever wrote it
> > intended minibuffers to use fundamental-mode whilst active.

> I'm in favor of introducing a `minibuffer-mode`.

Thanks.

> 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.

At the moment, fundamental-mode is activated from read_minibuf after "
*Minibuf-n*" has been selected, but before minibuffer-setup-hook is
called (which is as it should be).  It would be easy to call
minibuffer-mode instead.  So we are in agreement, here.

> >> For my case, I want automatic paren pairing and editing in
> >> eval-expression.
> > That does indeed suggest we really want a minibuffer-mode, rather than
> > just fundamental-mode.  But surely, the parenthesis pairing will be
> > dependant on the sort of text you're typing into the minibuffer, so it
> > can't really be connected with, say, minibuffer-mode.

> The way I see it, `eval-expression` would want to use a new major mode
> that derives from `minibuffer-mode`.  And more generally
> `read-from-minibuffer` should accept an argument that says which major
> mode to use (I think it'd make sense to re-use the `keymap` argument
> for that: if that argument is `functionp`, then treat it as a major
> mode, if it's `keymapp` then use it as the keymap).
> It would also provide a cleaner way to do what we currently do via the
> `minibuffer-with-setup-hook` hack.

Umm, why?  Do we really need all this extra complexity?  Having just
spent an extended period of time struggling with minibuf.c, I'd be
happier not to make it even more complicated.

> >> Plus we also need a keymap for it, which is
> >> minibuffer-inactive-mode-map.
> > No.  That keymap is very low functionality, and almost useless, as it's
> > intended to be.

> Indeed, the purpose of that keymap is that you can press `f` (for
> example) into a minibuffer-only frame to open a file, but only when
> there's no active minibuffer in that minibuffer-only frame.

> >> It seems to me the minibuffer is always inactive? I tried M-x,
> >> M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1.  Is this
> >> a mistake and the offending commit was trying to fix this
> >> inconsistency?
> > Very much so!

> BTW: thank you for that.

A pleasure!

> > So, a quick summary: (i) the change in the minibuffer's major mode to
> > fundamental-mode was intended; (ii) there may be some problems in some
> > packages because of this;

> The minibuffer used to be "always" in fundamental mode in Emacs<24
> (since there was no `minibuffer-inactive-mode` back then), so I'm not
> too worried.

As you agreed earlier, I think we should put minibuffer-mode in place
for those minor modes which maintain lists of valid (for them) major
modes, and suchlike.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 19:30:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 15:30:58 2021
Received: from localhost ([127.0.0.1]:58711 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOQGQ-0007T3-3y
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 15:30:58 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41244)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lOQGO-0007Sq-4x
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 15:30:56 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7B36144031A;
 Mon, 22 Mar 2021 15:30:50 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 06E3844031E;
 Mon, 22 Mar 2021 15:30:49 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1616441449;
 bh=N8pAlPxTZpmus+ta6icGOIE1KxXwl8dV6fX8W0lWTw0=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=PR47cJE2RYqBuNCzkum8gcxEFrz8BRr1pWTzgCRq4rHDsvimd+kchN7uNmPoyCLF9
 T0FMgnIIK6FvwEzlstvsj4bXaJlbo1VoaVE/qyw5nUbRQ0Ey6vCE77/ziE4kX5mI+6
 EiwzevHHW2ytZto2QczKpPwAeURX7/kkh5cLQgA2tANko0pkYvD8mKHRTDcXQHopZu
 ABYk3bw2xbmk8b79KpSiKZqcN4wJK3n10Kdh9FZMNC4YFpUXsO7Pee6ggHaOsV1qyZ
 cUmeC4WrdG8fwIDA8I49FxPoTLXH0HojM/V7WCLBcMItZOmpYj4EH6uJq+uJ9S9hhm
 A+cghhP8FRvsQ==
Received: from alfajor (unknown [216.154.43.249])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5865C1202A4;
 Mon, 22 Mar 2021 15:30:48 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <jwveeg7q9np.fsf-monnier+emacs@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
 <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
Date: Mon, 22 Mar 2021 15:30:47 -0400
In-Reply-To: <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
 (Drew Adams's message of "Mon, 22 Mar 2021 18:40:05 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.103 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Alan Mackenzie <acm@HIDDEN>, Sheng Yang <styang@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> 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.

>> 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...

>> 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).

> 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).

> 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).


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:40:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 14:40:16 2021
Received: from localhost ([127.0.0.1]:58617 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOPTL-00043o-Ri
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:40:16 -0400
Received: from userp2120.oracle.com ([156.151.31.85]:37304)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lOPTJ-00043X-LA
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:40:14 -0400
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MIO9b2158395;
 Mon, 22 Mar 2021 18:40:07 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=vPHy1b6kfxIGbQVR3y8tbI7K9Ng4NuQngFBzs7Cwg7w=;
 b=bCI5uiGtkQ6gfU86SsWlHaO5mAjVWA6w4iR5Mg7AfSpcW0nUduVg+ljCYJE+nlk4b8S5
 S+oppXhaaMecaRAhMafAjPTEi9kGA9ktBTA6hhSPqzVZgJv5W4YQ0TAkLVcYNJ4loGow
 R4qHqDpWzGLuqyHqJadbs0UtvEya37EKYa1rbh2CnMOhByPJSbdRo2QfmnG2DkuWQ7i6
 KS/fxs0SONzRBFG+SYJkOgHu48SUPmJNFd9A/4H/R2f6fclTVMOqXaITJgAXkVsI5uby
 gSnCSCJ+dH4ZgGA9hv/3oCUCtZzCBvy98VWlgOX1uqEOu7fXvc5ZFjOsVyuvDpo2E8wa pg== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by userp2120.oracle.com with ESMTP id 37d9pmveg9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 18:40:07 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MIQZJh088865;
 Mon, 22 Mar 2021 18:40:06 GMT
Received: from nam10-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam10lp2106.outbound.protection.outlook.com [104.47.58.106])
 by aserp3020.oracle.com with ESMTP id 37dtxx9wgy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 18:40:06 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=MH+HcChyuim/8CW1jBr7PILz9XDTRZXEXxCjagzyXyYUd7RVo5B1prmZMJ/Nz0UdemxThj7RVAveYQPLpt0CZjD5sn8arsnZCaFdooF4khJ1nTRPv9TxugwVPlpeTULHxIIEAi2X7cDThZqKYT1kaHY6/JrxL6whjZcPfRv4ViqfOrS98tI1cRPD2Yzb9BtGlOCxuOTIyKifi9ZOk5+vRSLMRJl80ydw6BkMNd0wRw8ngFT514o4j+LvD4ZPbxAdNkxa3DwgBdLDt8RikAObfXOdF8+Ityt+bCtJ18TskG1SWtMh+DkW6KfEM74MNuiGsz71HOkFF27QVHFtqYbFyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vPHy1b6kfxIGbQVR3y8tbI7K9Ng4NuQngFBzs7Cwg7w=;
 b=fYFxur9vUl5nW2hy0QNz7542fEL3fJLDfO/sJTwWLwSZoWAJF1E2n7Ljer3i4/mLFT1Ybw7Ek0nzvu/IY1s8Ipyrs0A+iwsyB1xmvdLGWyWmjzO2IX0yjDyYTJjnW/c8IrrJ5uLiDxnoAADK8R1RpKGIdcCqNooB78G88oRlo2+wTvOA29IIwpXU2r1XFrF59BzbzvEycll8Y+Rwj3n0hkI6pAPYIm/4GUALfD3lznaPdOHIZ5Mj8X9hx/qYP7/C83oah3bAJlLMoAaDvxX9Lxi9Jwm/s8+DfffvCQwQz4bdjPMcWhnrm9bLRcnXJVNtEAsmbs3MM71Ln6bBBiu1ww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vPHy1b6kfxIGbQVR3y8tbI7K9Ng4NuQngFBzs7Cwg7w=;
 b=fGtEPAaY4LJjQrXASgN10WSHQ8tl1BxSKguOhHgu4dwEmGu49DJSEwv5KwUGMRSYkAUz1qDgt6lAquy63bGcgib5qPYysNVX0H7I+zN5QSL2mMVjox1AqYREsumEnaCYIkeCPBnm0pTsuK1DyhJ7WJ/EfRAlJI9ZLhkLD/bTHLs=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4411.namprd10.prod.outlook.com (2603:10b6:806:116::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar
 2021 18:40:05 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021
 18:40:05 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>
Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Index: AQHXH0bjCkTZGRWC/E2X/mGKfPiRn6qQU15Q
Date: Mon, 22 Mar 2021 18:40:05 +0000
Message-ID: <SA2PR10MB447460CF4CFB66E32BAC2C33F3659@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM> <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: iro.umontreal.ca; dkim=none (message not signed)
 header.d=none;iro.umontreal.ca; dmarc=none action=none
 header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c223c38a-95b8-42b1-4acc-08d8ed61e919
x-ms-traffictypediagnostic: SA2PR10MB4411:
x-microsoft-antispam-prvs: <SA2PR10MB4411AE687BDA47EC692AAFFDF3659@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bhMhSDgVHiBKP9GUPjybwQyDyiCWhSn/3T0RNatI5eZiiYwjmNuRr1oNrMhiLwDM5pV9r7HouxZzp9QZavfL0jefGfbnvulLVpB2VOWJGKMji/O53V4GzKPk6uJZL5D/4q83rUbgcAfeMyGDGk2ZWzJSXCFbNvZClDqET59RYhTue2hEUl0LSEETZJvf0I9fhfaXeLUwhEh0VUoOCpPlPzJtGURbyvw1SojsELrhog+xIvj4esB9oIzXBz1ots5pG5wf1tJf7/zCCKTcqw++QANgpLQ+N9z24TlOh2b5ptE5BQcuNYyaQajNgdoQSzw03tm/xvVHxI1VR5n85H3ui9y6UiLZssw3Gd1XXxH5y6Akr4760W5n3WS6Kc4x/WAihqEMHziDbbDJzJCHM5Q9lbyQxdUXvyq1iHfW8qkDtCCO3wBvc0vkNjz8o7ksLyhVVFZgMOhHkdPSJ/YtE5wbHMW2Oe8JvOep4vX6zVVfHPUr5JPyfdgFqzcTUW0+E0YE+R28zw4sz1I7uM17PFT+j2AeFsEq95Ag+0N7TIChPb4R77Vwo6/0/Dodkht47C9ojnOKFiWh9jvSWEwpMDmP+QORIbT8H0AbVb8Q40nrImUzW4tKdb4VB5dtD4/AmbL8eQHFMlZ2hal2o4XQdnHx1FaWhPULr8n1HvdwP+4buE4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(396003)(366004)(346002)(136003)(376002)(39860400002)(8936002)(66446008)(33656002)(66946007)(52536014)(2906002)(66556008)(66476007)(64756008)(4326008)(7696005)(38100700001)(86362001)(83380400001)(44832011)(71200400001)(6506007)(478600001)(76116006)(186003)(316002)(55016002)(9686003)(26005)(5660300002)(296002)(54906003)(110136005)(8676002);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?WQbVlXAyDItOrNMOP1E2jTD9hR4TDg5M25UXfez4GZlKrIe7esjUH/CvLRZP?=
 =?us-ascii?Q?q2F6Ixf3iFVutBYVd9+xSC5ZyIZtTnB+PrlC+KcRBfcXCA1KictxAkHkKSD5?=
 =?us-ascii?Q?/i2rWWSQ199eRRKUrJu9HQ7M8y5JfgcSQs1tcdcvBZRnTSfrErMi/q2bUGCC?=
 =?us-ascii?Q?cp/L253yuu2cwedRx9WQHy9q7+ocBxEg4Kg6YFWLT74KKiae4i8P5Ej+Pw3R?=
 =?us-ascii?Q?BUUmwcdHhT19XB/IDO7QQ2o4cjHLvmPYpQmtigbXTWVCaYYG0uLwvF3iGeHi?=
 =?us-ascii?Q?2ZwiOK9uvFpV6AhXsY0BGQ0YifJcSLpBKiTpcsu6Mh1AkGwtm0NdRR2xGuee?=
 =?us-ascii?Q?modfUzJU1iLcHzOFmIzwTIUSYAlPqEbeprlv8a8s2XemyOYT0W1FVN1YNWtp?=
 =?us-ascii?Q?j1tjV9tCQKwFKshMEsTWFDWhROtDuY6fTOmKH8bdFolzDVTPuoo99kTugZEw?=
 =?us-ascii?Q?wLYsfb3MgucH/YiqkJeN/ErEI4Q5pZ9HUCNYdgqBxo0KFXEzY3MuJcFp4v3h?=
 =?us-ascii?Q?X+j43bdt7CsLnUXiU12T7mdTtF92en4s7CUUIbk2aLylKkKXX8a/wUIBmPpI?=
 =?us-ascii?Q?xBMky74jGWKJ7F8+l8wnJzTTY1iQUHJm/QLomKaIoZni14nTgNm3hcGzLseb?=
 =?us-ascii?Q?OwmRW3P5zGM0cv3yd7cqvQJHOMLu9hqD/RCD/b5x/UX37QnnA2Clv5hXl71K?=
 =?us-ascii?Q?ZaAWrDnacYV5cfAW4UthwbltQspUT2QZWtqU+JcIcbVGGKdg8SPDorWDLTEw?=
 =?us-ascii?Q?TMPzHrfYdDOwfvxCC+rYCPx0EWkJ2LcARstPBuuPtxBH6C4cG8Sz7tCzlqj1?=
 =?us-ascii?Q?73hXibfUof1RsjZ8Lj1pSKpbivvPpLjxlOqk+MJPb+6WIFiUNN/1rcwY9qd1?=
 =?us-ascii?Q?ArNJN8z63jd57g7ArPF8gB8oFEms6xvuRUDVankiIHCfhtjgPC7Z0y+yx/4p?=
 =?us-ascii?Q?AyVTiClhI520qbrw5PWSl45URuJc95iIlwP9iBfWCgeeavsXWDJ9bRp0pZ9D?=
 =?us-ascii?Q?xTUbBzZ5bW8yVqf2HH/Ja+AMYTl5S1Sev0CQBBUHkPov/45Ns5KO7v1qCz/V?=
 =?us-ascii?Q?TTOg2uByjBb7NOCauwJzmhX1hLltEa5T9m4RvYRzNMk8cXaMwLBdpUxPsELa?=
 =?us-ascii?Q?rPbANW3Ef1c6XhrNFFSSBYrgbwuVy0KzxsRT4xhcjLTINAq/TPU410niRiGP?=
 =?us-ascii?Q?BaMBLvj4seOMzVR56ztU1MdULsjeK0LqQJTpkkYS9ngUIz/jFKkSMFnvNso2?=
 =?us-ascii?Q?cRjItvSke10yq+V3iPuDRQ8PY6htCF52kbVJcKpL8KLqimiQqir6i0SOPT4E?=
 =?us-ascii?Q?gJmgBE++OfDDLQTSCbQzu2+I?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c223c38a-95b8-42b1-4acc-08d8ed61e919
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 18:40:05.0727 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hTm78XV7GlGc/+A5Pk88C+rmlppxvHiMAzDaB5ssjSWgwo9J4xlwZZNfB0ZFFhgcUBGNKu1UTmD32B0dKQ/H1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4411
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 mlxlogscore=999
 malwarescore=0 phishscore=0 bulkscore=0 mlxscore=0 suspectscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2103220134
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 lowpriorityscore=0 phishscore=0
 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0
 adultscore=0 clxscore=1011 malwarescore=0 mlxscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220134
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Sheng Yang <styang@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> I'm in favor of introducing a `minibuffer-mode`.

Why?

> 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?

> 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?  What's involved, besides
keymaps?  Does parenthesis pairing and such require
a major-mode change?

> And more generally
> `read-from-minibuffer` should accept an argument that says which major
> mode to use (I think it'd make sense to re-use the `keymap` argument
> for that: if that argument is `functionp`, then treat it as a major
> mode, if it's `keymapp` then use it as the keymap).

Why?  What's the use case for changing major modes?

> 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?  Why
would you find that cleaner?

> >> It seems to me the minibuffer is always inactive? I tried M-x,
> >> M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1.  Is this
> >> a mistake and the offending commit was trying to fix this
> >> inconsistency?
> > Very much so!
>=20
> BTW: thank you for that.

AFAICT, the only "offense" was committed by the
misleading mode name.  I don't see why two (or
more...) major modes are needed.

> > So, a quick summary: (i) the change in the minibuffer's major mode to
> > fundamental-mode was intended; (ii) there may be some problems in some
> > packages because of this;
>=20
> The minibuffer used to be "always" in fundamental mode in Emacs<24
> (since there was no `minibuffer-inactive-mode` back then), so I'm not
> too worried.

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.)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:39:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 14:39:08 2021
Received: from localhost ([127.0.0.1]:58608 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOPSG-00041H-55
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:39:08 -0400
Received: from aserp2130.oracle.com ([141.146.126.79]:45598)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lOPSD-00040l-II
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:39:06 -0400
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1])
 by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MION1b028077;
 Mon, 22 Mar 2021 18:38:57 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=Ty+IJoOB05qLftmlZMP9FKIgg1mO8kbIiy739iRys88=;
 b=vjNpX/PlwXl0CabIAXHE7VbF7k8Pz2gI8A+Pt3brkDiiSe4WmiNNNoVQi5yz7vyek640
 oy1cySf/ixT4uPLrMoiayCBB351DqE8UsvRmFxp6/nxVJ3nIMhVnc17UAno0Q/LAYySS
 TgGsGN7v0JeQzR+NjgCgzjsbSXCBby8deNAcZgM6paJwbfnJ3SgnEl2AHq+rYomv2gER
 MIgdHCWqlU9huAXVmTE1HqQQRqNWpepmOkZ32CMaqN5d+L7AzRmz8MQrcJtyRaDbAXhp
 VeyhhR+xyuXoxf91QsHLMb7jfGsf1uCohl9eTnzoMgshrYKxuJjtx61VEyLYCIBsTmbH dg== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71])
 by aserp2130.oracle.com with ESMTP id 37d6jbckq3-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 18:38:57 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1])
 by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MIPLju067285;
 Mon, 22 Mar 2021 18:38:56 GMT
Received: from nam12-bn8-obe.outbound.protection.outlook.com
 (mail-bn8nam12lp2173.outbound.protection.outlook.com [104.47.55.173])
 by aserp3030.oracle.com with ESMTP id 37dtmnj47x-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 18:38:56 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=O1mSp3eBWsCM++sEjrmDyPKKbD6rn/ea0qgCtKSl9i5Q//uXnRIbucBJjtrmab5W+M+IJKwQ95/7etWzrddXZiJtJYA/nrBKqpbmnCdIMkgpmuAoUCKtkelfte3BXgDZEF8tt5/ykR2uDPP+5sZGbSlZGVFbTSTzT+ZJMNx1Pzm0GwJt+ro7Jcigx1mWZQaWuGXmSVDSpGQpT0cCxDeuGFwLL7fc4l+MdIIGlZ9zVhM64mXBPe6O+u4vtYh0ElOj5imgTqQ7lQjWWdU3sFuXyHGG1NxCtbyc/i4O7ayM5J/Y00u06GLHFLPIho0utrKRSV7FV+U/do1xIOfkjpDztA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ty+IJoOB05qLftmlZMP9FKIgg1mO8kbIiy739iRys88=;
 b=jlqqMbKVd9J5YFnh192LpAwBRs+PTJaSr54EfhtBSeqVWAxvNtetZz+feVwZn10YwazkQhfKBikK69GtCwIHNwpL4WiU6G4VxuxTpi8hH+mt8H0UVxyIimS3J70yP04Gwqk96FDXlqJF8mjcO3AzWAcgKpweP2pXY3/tp8BKgv1I3nE3BHdyH0ZNzjip4T1y3vo/biyAVzU5utESB1x90sy2tRII5Tuqb18JLVW0Dff0zf2jAuLnul+Z9InZxBngB2dnqtrkVrmZlYGBgkilk9KAOL8wm3gfhKdq7NZCkvQDnGXixCtPE1Hk1f25MbMvo3NH0/YFEJ1U2tAyRpW3qA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ty+IJoOB05qLftmlZMP9FKIgg1mO8kbIiy739iRys88=;
 b=aqdLEqMlpbKg5UmBm1URKq0m+90dZSM829XdppTR/Q/3bBf8swExbcoo01M6XZPqRO6Do8Qvo3LT6JI0QvpCYLAIitc20xF74cn56ER/VE7HDxqJ5sdDMuC6AAYPe2IMoes8wC82My2E0iDDezr9wJ00Ajk+EjcgPYjDoXQHhTk=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SN6PR10MB2479.namprd10.prod.outlook.com (2603:10b6:805:41::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.24; Mon, 22 Mar
 2021 18:38:54 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021
 18:38:54 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: "jakanakaevangeli@HIDDEN" <jakanakaevangeli@HIDDEN>
Subject: RE: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Topic: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Index: AQHXH0aawQknHPNxc0CVnEaK38+EEqqQT7EQ
Date: Mon, 22 Mar 2021 18:38:54 +0000
Message-ID: <SA2PR10MB44749FE8AE6D74D8C708C9DCF3659@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
 <YFiz0mFjJt6ePXUb@ACM>
 <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
 <YFjFcr15EUyNmRh0@ACM>
 <SA2PR10MB4474EFA866F722642F468CF3F3659@HIDDEN>
 <878s6ft5ze.fsf_-_@miha-pc>
In-Reply-To: <878s6ft5ze.fsf_-_@miha-pc>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: chiru.no; dkim=none (message not signed)
 header.d=none;chiru.no; dmarc=none action=none header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 03753ac0-c2f3-4d29-71cd-08d8ed61bf38
x-ms-traffictypediagnostic: SN6PR10MB2479:
x-microsoft-antispam-prvs: <SN6PR10MB2479239EA50CB55882F1C7B8F3659@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jVvVJT7YQOnARv7gcAKgDCkqYAiO8ThpX8ypooe4VaBB1tccgY1CXnq+fL0bsgpSo4xSxva659RulNtGhDblCnOaT+kpppEDrsA1B/LbaBJbf1eVUUnOpZBnX1PL7TTGOqhVmJAQ2gyYQRr9NMooTlTnVuWZkOn65+2MMpDN+BB3eD+N83Uyqi85VtQrLg1hca0I/za+TQBdoaebNTdN16jgVC8bwrwzKZ7WjSNQbQwcBlrkMeQfRcXA7BlmzCZdTg9GdyguNwxoXdD9GK+hVTqC+CBPWSTV41RBbWYNdA27odslZVtlmM/3ir2x44vxHBSctQdtK+Ay2fCovN/zbm7OtCej6NjLJfq8uwuMAT5u8RpyK8iteaKl+IBrlBf6J4l+C59XR42+jelhvW36GQREGMct5aP48S7FLy3MWbV7FaVFeWCa1FKoT5TpxxZlVnSld6lutZehZYpq2W4cFf9YtOMslceUG0wrfdWzY2f6e1mmPstXfr/dk6mmk4iI8UUYwOqfV5NAwX9oPVvP+we6v5d9j5F39p7E4W25ptFD0/KFxr+ypee0iQ70dZ6JBblRR6WGVjxzSqA5+2KMXG/gPIb5hjkn82Bws8yg7aYJVeG/Ifq5XCBOdtwSc7c+lIOAFRhxrykPTRqNXlxLS4d/NvHCyJ4EiyI/FLHTRxY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(376002)(39860400002)(396003)(366004)(346002)(136003)(6506007)(186003)(7696005)(66556008)(66446008)(4326008)(76116006)(52536014)(66476007)(64756008)(66946007)(9686003)(55016002)(26005)(5660300002)(2906002)(478600001)(8676002)(44832011)(71200400001)(86362001)(6916009)(316002)(8936002)(38100700001)(33656002);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?OmmcyruWp0SQi0pKAaQLPy5QYeUh1awvH6XpqFsG+U0jDvswY8q0D6wmT7SV?=
 =?us-ascii?Q?DiE/1JYz0ZhohyKfkx3nC8UeedgcfHCIJ3Ic+cxxXQMOJbjkA6l5QKPGY546?=
 =?us-ascii?Q?1Xd5QMPBH3sdUsjTLcSOwNtlb03n5Rbh98q6KM6YW5A046Mz15bh+kVBh9D3?=
 =?us-ascii?Q?NxA+8/zzFS3bONUkIlpbpu8PPzCn9IQQqo7h0bSBdrZXsFO5l/eQVCeRDHX4?=
 =?us-ascii?Q?XhNIheTQEWap1HRsEWB/BQBErEW7GPmZiM5U9+ywlA8GzWq5Li5O9qjC262U?=
 =?us-ascii?Q?BC6UzVy3jSPNabTaLS3i08s5Ynu3clk6cwcHrAik6FRcdahQeC5eNF9ixYl4?=
 =?us-ascii?Q?ys3bybW2oFvtvm+sXMBSYrnbiFigh3Bb20SdBGm9mnLmajR1Wv4xt6olfoG0?=
 =?us-ascii?Q?KBT36e8Cc5sspJxZhcTAjsxvv40XScBhBdNdnbQlPEr9krHM6FikrzfSAmvc?=
 =?us-ascii?Q?DP38r0oJRe9+2dFcBYsOghGYC9f0IyvKYqEZ5WrdywwRMaMgElUjS3v+bsTq?=
 =?us-ascii?Q?3gPd72AH3/+v9swsp3CKrU3NAWviAoy9WK8Va5LCMfyTcsBeg3NWpX392Kjb?=
 =?us-ascii?Q?PF7oOR+bAwnXYaN43k65cnAgjtD8foyoBa8p0/r835u9gkeCLjB+8XtzHxSn?=
 =?us-ascii?Q?8pWCsEBTTEwrjsTgxlB5Uq1Y5Zb5ct72E3eRzDU1l6yRRjaUum5bOBmLH/Be?=
 =?us-ascii?Q?IyWXccLT/iielFuaxN2HqrTpubvffhMTQkY0A/L3zibxVwIefialkhncyxlw?=
 =?us-ascii?Q?t1hjLbWEarXs25BR3Ja9DMGfXhgNCjswgqWCvuVeZ/wnaqvIByilobbT8snL?=
 =?us-ascii?Q?BZ3q0Jv1uqgYdZlEoDUsdmpaO1gX+sqqm6dXpGG2Gq5EUqWC21FVdYqVnRX6?=
 =?us-ascii?Q?oZV3A6mKLFSPuN7ZopeQk2ge1dY6pZgj2W7QOl+sRk3doQyxlfv809PHuY76?=
 =?us-ascii?Q?sw36rT1n4DZJLMJ9AYoLY3deGAUKugVJNL3D4qPmDwZiG2FgQZEV6z6Jv5nv?=
 =?us-ascii?Q?3wV3qB2zmhNG5CXHK9EM8yeMttax6QU4XNYCOF8+Z9b8bhKLsCLPWKBPjFtu?=
 =?us-ascii?Q?/4wn308O3iZnLj6nox9FR/V8U9iYtbHOQybORek//IWMUo6ia1y2VDVokf+1?=
 =?us-ascii?Q?ddVDYrevljd2xZPtlyR6NRsNq9SSk+jg2Tbktl6vCgRU/QBuPq9BDpE16HEx?=
 =?us-ascii?Q?Bd98lNlV3ZFmnXVcZjXK6F9kZ6EJ5X0RSrxlAb4sK2SrWKOQLBSlgQV4Epih?=
 =?us-ascii?Q?6w8saUxuxLf++cVZrrLT1lx0wBgRvF2Ltf9EKb+tAxN66DBe4/wMeSz+qEmU?=
 =?us-ascii?Q?AduA/quOnRJeFb+fCEwQT68/?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03753ac0-c2f3-4d29-71cd-08d8ed61bf38
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 18:38:54.7428 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MWQBUPo9YtuH+kXt7yK2Tt+0Srm8G8tTOjajvRLOBRMkY6JJ9nlN3cNxr0Hafa8+7YptkHPZ70H0M3HDaFDIog==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2479
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 mlxscore=0 phishscore=0
 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=916 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220134
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 phishscore=0
 lowpriorityscore=0 suspectscore=0 clxscore=1015 priorityscore=1501
 spamscore=0 adultscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2103220134
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> > 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?
>=20
> There actually is at least one immediate positive effect:
> `C-h m' from an active minibuffer used to claim that the current major
> mode is inactive-minibuffer-mode and confusingly listed its bindings.

Yes, but putting something else there is bound to be
just as misleading, or nearly so.

If what you describe is a real worry then a more
appropriate fix would be:

1. Rename `minibuffer-inactive-mode' (e.g. `minibuffer-mode')

2. Provide a mode description that says clearly:

   a. Minibuffer-reading functions provide the active keymaps.
      And list them, so users can follow their linked names to
      their descriptions.

   b. Explain that when the minibuffer is inactive the keymap
      that's active there is the following...

IOW, why have two modes?  One suffices, I think; it just needs
a better name and description.

And the description for the _active_ case - the keymaps - is
more important - that's what the minibuffer's about.  I doubt
that anyone ever even uses the inactive keymap (but maybe
there's some rare use of it somehow).  [Oops, Stefan just
posted his use of it.  Still - very corner/rare, I think.]

The mode description of the active case can/should say that,
in general (by default), you can carry out _general editing_
on minibuffer contents.  That's not so obvious, IMO.  (And
Emacs should make it more true, by making `?' and `SPC'
self-insert generally.)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:24:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 14:24:04 2021
Received: from localhost ([127.0.0.1]:58596 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOPDf-0003fI-U2
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:24:04 -0400
Received: from chiru.no ([142.4.209.132]:57680)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jakanakaevangeli@HIDDEN>) id 1lOPDe-0003ew-1j
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:24:02 -0400
Received: from localhost (BSN-77-156-43.static.siol.net [193.77.156.43])
 by chiru.no (Postfix) with ESMTPSA id 2278E1280050;
 Mon, 22 Mar 2021 18:24:01 +0000 (UTC)
From: jakanakaevangeli@HIDDEN
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: bug#47150: [External] : bug#47150: 28.0.50; Incorrect
 major-mode in minibuffer
Date: Mon, 22 Mar 2021 19:24:02 +0100
In-Reply-To: Drew Adams's message of "Mon, 22 Mar 2021 17:09:32 +0000 (1 hour, 
 10 minutes, 49 seconds ago)"
Message-ID: <8735wnt5bx.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>,
 Alan Mackenzie <acm@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Drew Adams <drew.adams@HIDDEN> writes:

>> Things are already broken, slightly.
>
> I don't see that you say how things are (even slightly) broken.
>
> [...]
>
> 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?

Actually there is one positive effect:
`C-h m' from a minibuffer used to confusingly claim that we are in
minibuffer-incative-mode-map and listed its keybindings.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:12:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 14:12:59 2021
Received: from localhost ([127.0.0.1]:58551 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOP2x-0003MO-BG
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:12:59 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1524)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lOP2w-0003MB-1Y
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:12:58 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AA01980A59;
 Mon, 22 Mar 2021 14:12:52 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0131D806F1;
 Mon, 22 Mar 2021 14:12:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1616436771;
 bh=s9LR/sV4iMEVLzDSfIM26mc+dVsiOc7bpOzqUE8Qsqk=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=g5AhqFhTwTp7r/zDNO68cMcVHJVGeySd97U9pkdZ6PJ/tF0X88wtDt6yu8uqpCqYq
 TOgVfY/p7eXZmMTLKhbQBKO1YK+WEU4HvLXjJDeR84PlY8Fzimw/13h2/NK0ahPPw4
 jFIYhLoPaA/c2QeFjVhbNXR2xtjz+2/t1cdqLmccEXOR2P7I668sH3QPjKd5+Rz3nt
 BZaguyEUfpsp7lBrCBcs7pGxqFb0SOaaXQVXgUy/bTvNMg7QMHIoBFWzNW6ImXNwDg
 GOiyH73+raIV4mEvl8im8jLzuNk6idOGZNlJRJZKGfrWEvBVs0zaR/FvLGtxSSmraR
 BN9CNpBmsFf6Q==
Received: from alfajor (unknown [216.154.43.249])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B436C12034D;
 Mon, 22 Mar 2021 14:12:50 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: "Sheng Yang" <styang@HIDDEN>
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Message-ID: <jwv7dlzrrfy.fsf-monnier+emacs@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
Date: Mon, 22 Mar 2021 14:12:49 -0400
In-Reply-To: <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN> (Sheng
 Yang's message of "Mon, 15 Mar 2021 16:58:04 -0500")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.096 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org, Alan Mackenzie <acm@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> I am not suggesting anything wrong with (minibufferp). What I have in mind
> is that it would be better if there is a mode for the minibuffer, so that
> existing packages can still use *-modes, *-global-modes, *-inhibit-modes,
> etc. to decide whether to enable or disable some functionalities.

FWIW, these techniques sound pretty brittle, so I'd put the blame on the
use of those techniques rather than on Alan's change ;-)


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:08:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 14:08:57 2021
Received: from localhost ([127.0.0.1]:58546 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOOz2-0003Ga-MT
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:08:56 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47916)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1lOOz1-0003GN-IQ
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 14:08:56 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5009E44031E;
 Mon, 22 Mar 2021 14:08:50 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B34C84402DE;
 Mon, 22 Mar 2021 14:08:48 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1616436528;
 bh=l2GM/zeVTPTkq2k+8xyGj4nBy1Q9RfijHgNIstnfd8Y=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=lTGw0yNZbGtutA1T7ZgbfQBVSZUYumeDTzQCQEoC+GlvzlUjqJ0W9rTyGbdz47468
 zPRmtErIlSSZaYlqEbbpbh3q7P7WdYrsU9+UXNJz106YBMLgaWCFnOCoYAb1CDkReG
 h+hPUXfgGgFSLKLS985D+ikiIHo+Onw4YW/P9Vr84oeZGmNeddmSCpP+faGrWGsYgL
 A8HmbHBNrtskxkag6R/8EFq55po7hxDij8d1PeApQym1WS+HtSAHhpUcyzuQjUw3pa
 HJHHaor7L84EVt3BPT9RSuzjM4QJCETMpuXL7ZXa6e6sUnvObOCDf310IDukZuqOlW
 0jopDT+ctfVxg==
Received: from alfajor (unknown [216.154.43.249])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D7D2D1204AD;
 Mon, 22 Mar 2021 14:08:47 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Message-ID: <jwvczvrrs66.fsf-monnier+emacs@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
Date: Mon, 22 Mar 2021 14:08:46 -0400
In-Reply-To: <YE/SAcvWKTxdVZVb@ACM> (Alan Mackenzie's message of "Mon, 15 Mar
 2021 21:30:41 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.103 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org, Sheng Yang <styang@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

[ Hi, perpetrator of `minibuffer-inactive-mode` speaking.  ]

> minibuffer-inactive-mode: the critical thing here is "inactive", which
> means "doing nothing", or "not in use", or even "sleeping".  The
> opposite word is "active".  From its name, this major mode was never
> intended for use in active minibuffers,

That's right.

> but somehow nobody noticed that the buffer never got shifted out of
> minibuffer-inactive-mode when it came to be used again.

I did notice, but it didn't seem to cause any harm and I didn't want to
get into the discussion in which we are now, so I left things as
they stood.

> I've been fixing things in minibuf.c recently, and when I discovered
> this anomaly, I fixed it, so that an active minibuffer now runs in
> fundamental-mode, as originally intended.  I did wonder why there was no
> "minibuffer-mode".  But it was clear from the code that whoever wrote it
> intended minibuffers to use fundamental-mode whilst active.

I'm in favor of introducing a `minibuffer-mode`.

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.

>> For my case, I want automatic paren pairing and editing in
>> eval-expression.
> That does indeed suggest we really want a minibuffer-mode, rather than
> just fundamental-mode.  But surely, the parenthesis pairing will be
> dependant on the sort of text you're typing into the minibuffer, so it
> can't really be connected with, say, minibuffer-mode.

The way I see it, `eval-expression` would want to use a new major mode
that derives from `minibuffer-mode`.  And more generally
`read-from-minibuffer` should accept an argument that says which major
mode to use (I think it'd make sense to re-use the `keymap` argument
for that: if that argument is `functionp`, then treat it as a major
mode, if it's `keymapp` then use it as the keymap).
It would also provide a cleaner way to do what we currently do via the
`minibuffer-with-setup-hook` hack.

>> Plus we also need a keymap for it, which is
>> minibuffer-inactive-mode-map.
> No.  That keymap is very low functionality, and almost useless, as it's
> intended to be.

Indeed, the purpose of that keymap is that you can press `f` (for
example) into a minibuffer-only frame to open a file, but only when
there's no active minibuffer in that minibuffer-only frame.

>> It seems to me the minibuffer is always inactive? I tried M-x,
>> M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1.  Is this
>> a mistake and the offending commit was trying to fix this
>> inconsistency?
> Very much so!

BTW: thank you for that.

> So, a quick summary: (i) the change in the minibuffer's major mode to
> fundamental-mode was intended; (ii) there may be some problems in some
> packages because of this;

The minibuffer used to be "always" in fundamental mode in Emacs<24
(since there was no `minibuffer-inactive-mode` back then), so I'm not
too worried.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 17:09:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 13:09:48 2021
Received: from localhost ([127.0.0.1]:58422 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOO3n-0005vu-PS
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 13:09:48 -0400
Received: from aserp2120.oracle.com ([141.146.126.78]:37926)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lOO3l-0005vf-TW
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 13:09:46 -0400
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1])
 by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MH73NT052968;
 Mon, 22 Mar 2021 17:09:35 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=e9nWlKbjzStFceDQJduu/bc42uMl54hsw/5YKIcxq8g=;
 b=P2i88JZL1NlhKS8mBUBKiuUkOGx8QZj1DhJV0ohyuLicF01XzPbMs1ScUBMsGzDPTT/x
 mgKL5RSg7B+BtvVKi48USa2assiBjgZo152nvSRfPJec24+lh5wzamchevsV2AeWBdJc
 E5+3RwkVlilu/lk9pClD4qR4KBY8e+v6rRncUIrERYTXijOqc05mWflIX4tafYRAoNI7
 cgTpxKU0jFl7W6whIxCIqD2FA6P36NWXyucUF61wY/9Hx+4NWdz8z1OmsERyGAFOLXLz
 fyQh+Z7SiObB0qKFWhLp1+7vTi9y/7H8BfubIDcrGiKxMTZYDOdwiCr+bT7GKtZwPotM 2w== 
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70])
 by aserp2120.oracle.com with ESMTP id 37d90mc6w1-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 17:09:35 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1])
 by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MH6J1t192064;
 Mon, 22 Mar 2021 17:09:34 GMT
Received: from nam11-co1-obe.outbound.protection.outlook.com
 (mail-co1nam11lp2170.outbound.protection.outlook.com [104.47.56.170])
 by aserp3020.oracle.com with ESMTP id 37dtxx73da-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 17:09:34 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=LxBI+Gn47e+T/rhow/b6ySWOdNpwVh2GkfH1T33v+E5GgWrTs9GBRaQpfvUWAkWpiGIG3OB/Q0+lN0lUFTY6pjnswNktReJISEjC6Tw9dgFc1iaUDBtCOrg2reTTBlTumvJNk3PaqUkfzaw2OZe5nFqPRRBxulKQ3orZKRbbLtKg2JBYyOMC0MCTv81gEtkLo/5mmD17ivq7ys7kch0WqugfTISPFTmi486Duws5o5PKjIt7dpcwxUu124MSmeIzLqaaYlEdKrrq1LAtIiFelqBicy/jSI/8NvVOKE+cbTP1pP4Ft1tReLhhtZVbzBtyyzgZ9BcZSogSZG+kTwyjBA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=e9nWlKbjzStFceDQJduu/bc42uMl54hsw/5YKIcxq8g=;
 b=lt2H5uC08qvgiJWwxB+uOWIXDjJi7mie+ZjfAJglfokwdlx25RmEORRJhYIB4P46QeQ53iF+c29gnP5oOeOSBb1Rh1e2AypYxs84hmQjUjG6XxT2wor9z5LiynyW8SfOYaMTlh9sNkhkNjYla/oWu8shOtt5b19k54jvbmLu2llzMQc+pA9CHOBfLXK7Pj6LSwKPMAKXuR8yVhidleN8ZoUHTiGz/5skdqu8fwkrzkOxL3P+GiQ+ZovK0Xfl0fQ6RR1OSXjudBfRzBr0zg3k+2JNrvjbpuY7VD6cmpBnTdkU5vn2OV0oxe0ktwDImLRbqm8gAaAoY7E2xVSTPCYfFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=e9nWlKbjzStFceDQJduu/bc42uMl54hsw/5YKIcxq8g=;
 b=HtSGslxOmn/7C/NH8ajHaONxjKAh4oWStdQCzW5vLcapVcgmdEjJpSJD+nRfOlOnKETMRpZrs41pKJgsyQJoJ9Jkd5nuc0o35SP3xWyToljsODAN8NxFPFBT6+g2z57rlALIo0d3v7Ir+gWDDOfGgOI28KRGu/NUSd/oiD2YUNY=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4411.namprd10.prod.outlook.com (2603:10b6:806:116::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar
 2021 17:09:32 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021
 17:09:32 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Index: AQHXHzhGkdcXS6vwFUSNlV7whKGfDaqQNpzQ
Date: Mon, 22 Mar 2021 17:09:32 +0000
Message-ID: <SA2PR10MB4474EFA866F722642F468CF3F3659@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
 <YFiz0mFjJt6ePXUb@ACM>
 <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
 <YFjFcr15EUyNmRh0@ACM>
In-Reply-To: <YFjFcr15EUyNmRh0@ACM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: muc.de; dkim=none (message not signed)
 header.d=none;muc.de; dmarc=none action=none header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3eb942e1-3587-468f-9dfe-08d8ed554333
x-ms-traffictypediagnostic: SA2PR10MB4411:
x-microsoft-antispam-prvs: <SA2PR10MB4411C6A269E071BAFC80313DF3659@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ts/fyT83m39teSiZKq19b+9JbCAWg20vaz6Oy2rE+ik7kkPS0os+XHxtctBwjF5HM/qqKEwJ3jzFvSnmzNHTJNONqq+2/hFw9tr/coojZkZOBmDpatklpUQ62vguSeRldDpdfVvE4NvRIzkZ/sQ3lpHvz3kBtJGm++mfYCKVWN/9VDEaHettdImaj9j++okIIsdFYXIs3lZ+VIiI4WVMU8kvAfTdsbCeBKho5BJ9w08CntZIaFbOJI+zT8ju8gwPRI7XYZM9SKn6WOMO/EVVjLpnH+BTVgK5EM64OEH3NHgu1cuky/QFuSZ5qKbe3F9+6Jfl3bGi2bTG6epOSr+9MCM8IMUOrrJkIRp0ya9zrTzEIQ9MO1hXqtabTrkO+vgoi19uo/h/I3VUezwb/HL8WIhh+s3A8RhbLnzbUWOfjUUPjVdCfAP1t8vOH7PHt/qsXHLzhB7mFPF897NyqJkIqyTh3ueZiC0kN0KQ9DVqdSNtM4bdf0JU08hycBTHw+yY/6CbJ67IOVwi6C125nA6jNz9NHUREq60fNnPqTImTX36u/HlVxrJOnybJGPt988farL+Fp5isApXdVw9BPKNGwJE1T1sBri8JCX9Va4nul6O302+nADIkMFcRS4pITFUKjzc6WqcY0UXzpkVC8908SQY5HP8Ps0J7uU+Vx7WGQ8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(39860400002)(396003)(376002)(366004)(136003)(346002)(8936002)(66446008)(33656002)(66946007)(52536014)(2906002)(64756008)(66556008)(66476007)(44832011)(4326008)(7696005)(38100700001)(86362001)(83380400001)(71200400001)(6506007)(478600001)(76116006)(6916009)(186003)(316002)(9686003)(26005)(5660300002)(55016002)(8676002);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?E9vU5Led86c5KblEMWz+BANYPT4sWsEWvign3Se4rrusCTSesmiFIubneO88?=
 =?us-ascii?Q?PHs7XvSQt/8BFm2EVNa9Zjt1XrXDr9hKD0CZXLwUy9hZo3n05lIUZ1f1KAH8?=
 =?us-ascii?Q?j8q3muGeKYUq3yyZd27evtoGCozxwFBC42SmAbZVYgkD1BFPs6QZb0KoncMp?=
 =?us-ascii?Q?0dR5heoVpyfOs4hHjlnH8PBO9/fE7t3yD3j09kxoWNfo7lzDnhwV0pm0F+sg?=
 =?us-ascii?Q?yO3FGrlFrGRfyKMuOROWQTE7iX/RuNTIxafvZpe3uLvu8uo3jQ8ukOW1xqp0?=
 =?us-ascii?Q?QUkYoSF4MNOP83MgBPhvSjCErhhIxapqFCEvJyLnNNLIDdk+fguAJB+sHFFD?=
 =?us-ascii?Q?ZZ0Dc6Iroo6pcWdhm8Aa6PemwjmMbcrAgn/YY7kWHDhUqPDP6K8auR833ABJ?=
 =?us-ascii?Q?Ja771/X1jIVUfFLvzSBeIaJjPjVsYRP4ckcn4UEX5aA7ONPSzLJeQ7jP0TLr?=
 =?us-ascii?Q?Ow8FdoSfNy7c6QZ8jTBg3fvS8qeESh4rk1RNBRXaUP1jZGKTTTOQjsqeFIip?=
 =?us-ascii?Q?kfNC9FcW/f9xmW1mJ4SenW2651VPJY1lK5VQtJBO7+J79fhMDKBvj+hOH9Op?=
 =?us-ascii?Q?8/jyIw2KnHeS3IGNB4rdPB+eecHxwi/8GdlhWgl4WdAEapT5/TOMhCZ6Fy9b?=
 =?us-ascii?Q?kHj+SvX1h8xnRBo+YTxOVYB6OsBsdObs5Yj0EJrc/54vTrr0/PpyhsIF6nW0?=
 =?us-ascii?Q?/T6jgoi7hohrE1SN50JNn4HtUyt69RDNmkU5tYoqT/8LwFSPD3tEVJxBEDUO?=
 =?us-ascii?Q?4uvCjM8xMMndegUsCmoXTgLL1yXpV3wIDlmBUR8oU2HxT/RUxCdz+X3F5aVt?=
 =?us-ascii?Q?/NFkoxO9obFpszeaAMYJut/S2lIUYrc55VlCh3qCraAhvKblfAE6FbtP3GwH?=
 =?us-ascii?Q?BO1h3qgnzE/xZ+cDjxRZnXmc2876MaJOQqkSS0ZGTP3emb7XXtrfL4QmUd58?=
 =?us-ascii?Q?xNVy8ie6udAsIhh6KdefyJOknOoSbFKXH6B7zfiSvuZXdrI+vUC5/uQZqLCs?=
 =?us-ascii?Q?9G3usdthmMdG0aTACc/J0OUoO7vtKU0O+7Ssp5Wcrg8uAGWia1aTa4qyWF6g?=
 =?us-ascii?Q?x6RN2ulGwGQCvL514fYwk6VLkG56wXIqLikhkH942BjyCw9ioFsZOpB/VuIO?=
 =?us-ascii?Q?pzgldPju/0gZdRHyc1jydIm9QDursj6GMleIOgeZ89cjuRvpxhmam+AOfAAt?=
 =?us-ascii?Q?tBn2FdKTRCGqEoJ7+pH+c7W7AvSBEzVezAlOKCxGt9X1b6ivki/9Re+sJjSO?=
 =?us-ascii?Q?kaFYv6DVHg0qBniuUciSkgn0tf+F1SA3o5gq6K0+w5/zFjkbQuZuX37PElzK?=
 =?us-ascii?Q?XsNiJMXHuO5L1z4RmZPBklAf?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3eb942e1-3587-468f-9dfe-08d8ed554333
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 17:09:32.7906 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Bu6grOkt2nQgVqQKKynqgsRAxQkggwCFMiKu8APPm1xzCClRQBZF9vzVHYTKFAykjI/rKjyxowp3vFVJm40fpA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4411
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 mlxlogscore=901
 malwarescore=0 phishscore=0 bulkscore=0 mlxscore=0 suspectscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2103220123
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 malwarescore=0 mlxscore=0
 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0
 phishscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220123
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> 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.
>=20
> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 16:27:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 12:27:39 2021
Received: from localhost ([127.0.0.1]:58343 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lONP1-0004q1-Fc
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 12:27:39 -0400
Received: from colin.muc.de ([193.149.48.1]:22403 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lONOz-0004pn-LB
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 12:27:38 -0400
Received: (qmail 42567 invoked by uid 3782); 22 Mar 2021 16:27:31 -0000
Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 22 Mar 2021 17:27:30 +0100
Received: (qmail 7830 invoked by uid 1000); 22 Mar 2021 16:27:30 -0000
Date: Mon, 22 Mar 2021 16:27:30 +0000
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Message-ID: <YFjFcr15EUyNmRh0@ACM>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
 <YFiz0mFjJt6ePXUb@ACM>
 <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>, acm@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Drew.

On Mon, Mar 22, 2021 at 15:52:13 +0000, Drew Adams wrote:
> Hi Alan.

> Sorry, I can't speak authoritatively or specifically about this.

> But I fear this will break things - just what, I don't know.  I use
> minibuffers a lot, in various ways.

Things are already broken, slightly.

> I fear that because perhaps no one will be able to offer a concrete
> reason why you shouldn't make such a change, you'll make it, and only
> (much?) later will we find out that it's broken stuff.  And then we'll
> hear once again that "That ship has sailed."

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.

> The minibuffer should be available by default for general editing.  It
> has its own keymaps, etc.  It may not matter what major mode it's in by
> default - that's my guess, in fact - but then again, it may.  And if it
> doesn't matter, then why change things?

An active minibuffer doesn't use its own key map - it uses the key map
supplied to it by the calling function.  This is how being in
minibuffer-inactive-mode (which does have its own key map) "worked" for
so long.

> Why do you find a need now to give it a special/new major mode?  What's
> the real problem you're trying to solve?  Or is this just another case
> of looking at the C code and thinking that something isn't "consistent"
> or "complete" enough?

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.

So the idea is to allow these minor modes to specify minibuffer-mode.

> Is there a real bug that you're trying to solve here?  If so, what's a
> simple recipe to repro it?

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.

> Apologies for being skeptical.  Likely this will be of no consequence
> (but then why do it?).  But maybe not?

No apology needed!  Thanks for raising the points.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 15:52:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 11:52:27 2021
Received: from localhost ([127.0.0.1]:58292 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOMqx-0003uw-Dw
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 11:52:27 -0400
Received: from userp2120.oracle.com ([156.151.31.85]:52590)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1lOMqv-0003ui-Gh
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 11:52:26 -0400
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MFXtla087500;
 Mon, 22 Mar 2021 15:52:15 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=corp-2020-01-29;
 bh=mZ+PPj3egXB+EMxzYE9n8u/zbcj9FXSYRepYelh8YwY=;
 b=sPwcMxywh7OQ0D9uRgqj8G7LDr8EbrcZCeCSPxLtHfHsuuIrIPrnAjYc5OncOeoyo55+
 cOempsjsQHztb230Ok/Qi12pvtE7DTQeJsjrNJOeleXhuj3NHiL2hVATTGa6PA53UO+p
 FsJYh+4SjyCjs+011lpnylIkaCQuNbJ9MDnu0hLyGssWBSw9yHDvKAIeZW+UQ1ng8al7
 glC3HZh9WHkFJqipNYdn0m0IhgF7oPG0iK2YNjyNbe39+FsJMmnMH8YhyibXvtVgJB7r
 Jbfw4+JsBjh/KivZaoEsq2uNwAw2BuAa7WvKvbr4R8o5N8uOwYBUm6PyvMNkfpSYmE7i lw== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80])
 by userp2120.oracle.com with ESMTP id 37d9pmuwnq-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 15:52:15 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1])
 by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MFab6W059276;
 Mon, 22 Mar 2021 15:52:15 GMT
Received: from nam12-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam12lp2176.outbound.protection.outlook.com [104.47.59.176])
 by userp3030.oracle.com with ESMTP id 37dtyw8pqb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 22 Mar 2021 15:52:15 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=li0VHrsKyJhN2LTsG7lhOfq5uyi777AMDXZanZ8FhiWWn/e3gqpBWUFj5c3xkGFt9045PHCIBezhnKLts30AL71G5UWkgvLUxFJDiQauyI2VLeDAssOYpEID19Gj14srVITM9Gtpb9HAdbIILEebkowGrc25ymAcNraVsmkav7mHJehsLHgZzfNOnRLQtDE8u5kNWKz9XMi5oAbsr0nKplbT1ogI33ARFmQVvALoIVFzuLmXeKXWyH4tqqodVYtDi05DRg4WpxTBviCOXSZH4oMN2MDDh+dY07y5KLdGBikZbfIX+0eOSVcHMN5pEpDKf6o624kyUZHUa1GK9MaW1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=mZ+PPj3egXB+EMxzYE9n8u/zbcj9FXSYRepYelh8YwY=;
 b=kglwl+fbLitQq1bV4T+9svTLMhaBTKlE509l78qXlsTjNBw/Y7AKiPb9jjdDtn2gYlukHBVlly4xJ8vW5lfaTHmyYRHpC6ZEmGoeYNgTCup2g2kssHPrzZBvoSXlINwJoa71IpfyL7XWqS/Cd6M0/p4EHoW25UNEPw1hJjQEPFaax8IsMyUaL96c2sNfvxUTur31O0diccz7CwiIzhR3L7zNGGtylReGK53woHSwttLKKj9Lj1DafMy+ISExI0KjMxt5szCFcH6A5TmQb1ecf6+evvjoj2upQDh8pL94eImWCjF4HuKLGeDw9R+zTOSjJ2R7vWM/CUN1M4a/N6TQ7Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=mZ+PPj3egXB+EMxzYE9n8u/zbcj9FXSYRepYelh8YwY=;
 b=XZVMVwAuc0EM310LOyqPOwr4prIsFEjhmF9wHE/fcPhrzfg8KvzZbM11E0dQ1MJMppMc8JqTJZcoVja3+My0X11BPUr19JtYw277HQTlXAD0nQoqeOP12KLH9RHemcPU3bIsrQAUn9o3/IiSWo+lGsubeMG9TejkIPN0jjp+CDY=
Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15)
 by SA2PR10MB4588.namprd10.prod.outlook.com (2603:10b6:806:f8::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar
 2021 15:52:13 +0000
Received: from SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com
 ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021
 15:52:13 +0000
From: Drew Adams <drew.adams@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Thread-Index: AQHXHy3loRhmbplnOk6CuxGlsSCTQaqQIaXg
Date: Mon, 22 Mar 2021 15:52:13 +0000
Message-ID: <SA2PR10MB447451107823C74765DCFE6EF3659@HIDDEN>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
 <YFiz0mFjJt6ePXUb@ACM>
In-Reply-To: <YFiz0mFjJt6ePXUb@ACM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: muc.de; dkim=none (message not signed)
 header.d=none;muc.de; dmarc=none action=none header.from=oracle.com;
x-originating-ip: [73.170.83.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 20886578-563d-4175-9c04-08d8ed4a75e5
x-ms-traffictypediagnostic: SA2PR10MB4588:
x-microsoft-antispam-prvs: <SA2PR10MB4588CCD527BE53E92522AA6DF3659@HIDDEN>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hoPBK76oUfr8/SbIWhqJ0+gSsmzpyDJwq58rz2hPkQRVTPx5BoMVSU5l/yvMKd1hoz1uqZ2yOWt1txRSQBftxH6cHo/R2NbPcIaoCHgEvQqFAvH3Jpd/L+WghwW1yFhwQc6xQAjmXAslSCQZWxIOkK4sOEfxxQViqdbPK0ipcws7dG2zDTwKIOqQbdvEkpPYRdHVx7vlghRJYBfOeMgAurfUDZ8HxgkEeN06TuiMF1svUequf6gh17uZoidiGHzQ0w/p9OuaIYVk0pVeKk6hfS+Y9h0/J89oxsUFX+0eSuzHJADTNMnySerm5R9XC/hiCk4qrz+ST4tzeV3S3DYLNHfRPN69Az3muY7FR3vOvaq1TNwZnoXAqCJbx0vnNPsjsmMQ3dWlyonJDoqNJfFUD/B20gO2a2RFDdCepM4PrEo++M+BhBKKAYDNtBpSdkSJJ4hR9dxFsv4SE19phKmcrK34rsX9AJVONrwzs+ODNVM2ldAlhse9xiUTxA0R6kNsaHQkB71Q/eSKYAMGkQEesN6X2LtjWRfZocZ3GshZ04460NFGSxpUOPFylHB++VrYFZF1CJXUXILVyo30dYXrm8kbZpjblpnggI6TwR35RJKaf2BSjfILZdEMreLDEd/Rfneud6eNrnJi9VV8UoaelLlid9pLU1iTXPS7zAOG/5k=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(396003)(376002)(136003)(346002)(39860400002)(366004)(8676002)(6506007)(26005)(186003)(9686003)(33656002)(44832011)(7696005)(66476007)(66446008)(5660300002)(52536014)(64756008)(76116006)(38100700001)(66946007)(6916009)(316002)(66556008)(4326008)(71200400001)(8936002)(55016002)(478600001)(2906002)(86362001);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?OUpJdW94WUxDcWM5STZLQkx5VmFDSXdpYmhuc29MalZUc3VIWS9nUnpERkhF?=
 =?utf-8?B?UUY3ek9VSDFraDlYZy9VRGhXQVo1dDdmRGxqdTlSM2JxeU9HNzhtTit5eUZk?=
 =?utf-8?B?NTRvNTdFMGNqb2xyZkhSMG9yeUFKU1pRbEM3eW5jaE1DeWJlUTZsSFc5aEtl?=
 =?utf-8?B?eTFzUzczNXF3TVhzV2NUa0JSUVhmclFjUHUwVThxTmQwa0NLeWxJY1FYUEZE?=
 =?utf-8?B?NTRqKzJadHprV3VxTE8yc3Foa1JkK2M1RlZCbjlEUGJ1YWoveWVLVmE0REhJ?=
 =?utf-8?B?YjZzNTMvNDI5UVBzUExqdW9XMlNxcGxWS3hDOUhtZTJIR0JIckVYTnl2aEhX?=
 =?utf-8?B?d3BQNjczYVhEb3pqeERhR2Z2cHltUE1jRTdXcUl1S0JBN1JhSG11YUhvNDRP?=
 =?utf-8?B?ZlBGMWVRb1UyYVBRb2tGUnAvWUhBSkxaaGc5TkQ4Qk9ranpUOTBjYzNGT3ZD?=
 =?utf-8?B?Y00wb3lrZjg4S05FM3V4blY3bFVkVVZiMXJNNFZFdTBKbThIaG95Vjc5L0Vs?=
 =?utf-8?B?RzhQYU5NNEtuNVJmd0xtaGZMT3ZMQXpzRFY3WTFLRkFQSXBheE91aGdNdEl1?=
 =?utf-8?B?aXBoR216cGtJcG5qdjVwT00ydjRVdGxpOTBxbWJFZ3B5dHg1KzRPQ0MxOGdK?=
 =?utf-8?B?QkJJbHptaHlMZHhpTGVJNHdDYVBLVWxJcldFSC8xMzZPeE81Wk5rRCs3RkJI?=
 =?utf-8?B?SXREaGhEaXJWMzRXR3VnYnRndGhic3pGRkdIMG1vTWpqTVJVeWJtL0JmTXZw?=
 =?utf-8?B?WmFscDJ1ZERjVDJhQ1lPMWE0WENLanoyZGVoWnBUMTViZDd1dHYrSDVkdlhm?=
 =?utf-8?B?NnVWd2Zhalh0d1ltd1lHeUdIcUV3eCtvT2Q4NkhjVHhYUUQ0Z1lCS0xOenE2?=
 =?utf-8?B?ZXd5L1E5bWJONXN2bGYreGdPTGZjOFRkRU10Sk1lZFBtZWlTd3dzTC9FYnlC?=
 =?utf-8?B?c2pnWTAyUklFK2lEenRnR2hZd1hOU1ZBM3YxN1NnN0h4bkVIMVh1TEZUTmxK?=
 =?utf-8?B?eU5BaVhMdGd1L093M0NmL3pHeDVpV25Kd0RYQ2E0ZjVKTzVvd3dKcVZwQnlo?=
 =?utf-8?B?ejZ5TWxDblBVUElBSHhvUHpOYmN0azU0T2JVblZlZmJITVRBS3NuMklYRlU1?=
 =?utf-8?B?N0xOcDBRRGRrUTAvMGc4TGxGWktjcDdJbzNrdWJmb1BnNmRUeUtYVTJ5c0RT?=
 =?utf-8?B?eGdMQUZDajVTT3dKUWtjc0NvWUdBRitpNzhxRXFtL3NhaVZpM0RkTHk1OGFP?=
 =?utf-8?B?V0dHSWVBSnRJSWRvUS9LRUFPWU9jSVYxcllUQTRzbGtxaEZHR045QXgrbEcx?=
 =?utf-8?B?bERXbWFiNCszRHorK2V3Z2VmeFV2WXBjYWJNOVY0bCtkYXdSMm1jK0lTMmp4?=
 =?utf-8?B?ZWdlS1podW00eU5hZlpoVS9MVUNXaUVXbGtSWGttR1dTZDBCYnltaCswL1Zq?=
 =?utf-8?B?YkxqOUVvUSsvU2IxMjRiQUxCekd0ckFpOWpPRzNibHJIRUV4SVpoL0QrUTlq?=
 =?utf-8?B?TmZsY3VxNHp1ZFFkMWxXWGZITTRtTEpXdEk1UDZVSlRwd1J0SWxsMW02SzBB?=
 =?utf-8?B?TWFJK0dVbmVDb0RTSitFa2MwRDFNV1BKUUNqNGFuTTVpT05lQjg5bHl1YnJS?=
 =?utf-8?B?aGhhTFZLbjNBTFdLOGtpb3hoTzBldFAvZlFnRURIRUMzRFVidnFPNzNwNjIx?=
 =?utf-8?B?T2g1eHorOHlTT09HajZiMEdla05oeEowRXFGVVVTdEozZ3FhV21lWkd1aE5H?=
 =?utf-8?Q?vjNJgIzZVTioFo/ho4=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20886578-563d-4175-9c04-08d8ed4a75e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 15:52:13.3821 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kJazsr/b7iSFLgGMGOsIy3xngrW0IzfevhE61Xpmjkjs1nWakzk1SrF9eP3sGjGQrbqLjudQmq/RpeOx3BLsRw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4588
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 phishscore=0
 mlxlogscore=669 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220111
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931
 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 lowpriorityscore=0 phishscore=0
 mlxlogscore=970 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0
 adultscore=0 clxscore=1011 malwarescore=0 mlxscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103220111
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47150
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

SGkgQWxhbi4NCg0KU29ycnksIEkgY2FuJ3Qgc3BlYWsgYXV0aG9yaXRhdGl2ZWx5IG9yIHNwZWNp
ZmljYWxseSBhYm91dCB0aGlzLg0KDQpCdXQgSSBmZWFyIHRoaXMgd2lsbCBicmVhayB0aGluZ3Mg
LSBqdXN0IHdoYXQsIEkgZG9uJ3Qga25vdy4gIEkgdXNlIG1pbmlidWZmZXJzIGEgbG90LCBpbiB2
YXJpb3VzIHdheXMuDQoNCkkgZmVhciB0aGF0IGJlY2F1c2UgcGVyaGFwcyBubyBvbmUgd2lsbCBi
ZSBhYmxlIHRvIG9mZmVyIGEgY29uY3JldGUgcmVhc29uIHdoeSB5b3Ugc2hvdWxkbid0IG1ha2Ug
c3VjaCBhIGNoYW5nZSwgeW91J2xsIG1ha2UgaXQsIGFuZCBvbmx5IChtdWNoPykgbGF0ZXIgd2ls
bCB3ZSBmaW5kIG91dCB0aGF0IGl0J3MgYnJva2VuIHN0dWZmLiAgQW5kIHRoZW4gd2UnbGwgaGVh
ciBvbmNlIGFnYWluIHRoYXQgIlRoYXQgc2hpcCBoYXMgc2FpbGVkLiINCg0KVGhlIG1pbmlidWZm
ZXIgc2hvdWxkIGJlIGF2YWlsYWJsZSBieSBkZWZhdWx0IGZvciBnZW5lcmFsIGVkaXRpbmcuICBJ
dCBoYXMgaXRzIG93biBrZXltYXBzLCBldGMuICBJdCBtYXkgbm90IG1hdHRlciB3aGF0IG1ham9y
IG1vZGUgaXQncyBpbiBieSBkZWZhdWx0IC0gdGhhdCdzIG15IGd1ZXNzLCBpbiBmYWN0IC0gYnV0
IHRoZW4gYWdhaW4sIGl0IG1heS4gIEFuZCBpZiBpdCBkb2Vzbid0IG1hdHRlciwgdGhlbiB3aHkg
Y2hhbmdlIHRoaW5ncz8NCg0KV2h5IGRvIHlvdSBmaW5kIGEgbmVlZCBub3cgdG8gZ2l2ZSBpdCBh
IHNwZWNpYWwvbmV3IG1ham9yIG1vZGU/ICBXaGF0J3MgdGhlIHJlYWwgcHJvYmxlbSB5b3UncmUg
dHJ5aW5nIHRvIHNvbHZlPyAgT3IgaXMgdGhpcyBqdXN0IGFub3RoZXIgY2FzZSBvZiBsb29raW5n
IGF0IHRoZSBDIGNvZGUgYW5kIHRoaW5raW5nIHRoYXQgc29tZXRoaW5nIGlzbid0ICJjb25zaXN0
ZW50IiBvciAiY29tcGxldGUiIGVub3VnaD8NCg0KSXMgdGhlcmUgYSByZWFsIGJ1ZyB0aGF0IHlv
dSdyZSB0cnlpbmcgdG8gc29sdmUgaGVyZT8gIElmIHNvLCB3aGF0J3MgYSBzaW1wbGUgcmVjaXBl
IHRvIHJlcHJvIGl0Pw0KDQpBcG9sb2dpZXMgZm9yIGJlaW5nIHNrZXB0aWNhbC4gIExpa2VseSB0
aGlzIHdpbGwgYmUgb2Ygbm8gY29uc2VxdWVuY2UgKGJ1dCB0aGVuIHdoeSBkbyBpdD8pLiAgQnV0
IG1heWJlIG5vdD8NCg==




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 15:12:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 22 11:12:28 2021
Received: from localhost ([127.0.0.1]:58272 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lOMEF-0002w3-Us
	for submit <at> debbugs.gnu.org; Mon, 22 Mar 2021 11:12:28 -0400
Received: from colin.muc.de ([193.149.48.1]:20296 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lOMED-0002vo-IE
 for 47150 <at> debbugs.gnu.org; Mon, 22 Mar 2021 11:12:26 -0400
Received: (qmail 90971 invoked by uid 3782); 22 Mar 2021 15:12:18 -0000
Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 22 Mar 2021 16:12:18 +0100
Received: (qmail 6515 invoked by uid 1000); 22 Mar 2021 15:12:18 -0000
Date: Mon, 22 Mar 2021 15:12:18 +0000
To: Sheng Yang <styang@HIDDEN>
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Message-ID: <YFiz0mFjJt6ePXUb@ACM>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
 <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org, acm@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Sheng.

On Mon, Mar 15, 2021 at 16:58:04 -0500, Sheng Yang wrote:
> Hi Alan,

> Thanks for the detailed explanation, everything makes sense now. I
> still would like to clarify the following

> > As you say, there is (minibufferp).  What is wrong with that?

> > That does indeed suggest we really want a minibuffer-mode, rather than
> > just fundamental-mode.  But surely, the parenthesis pairing will be
> > dependant on the sort of text you're typing into the minibuffer, so it
> > can't really be connected with, say, minibuffer-mode.

> > Sorry, I don't understand what you mean, here.  How will the use of
> > (minibufferp) prevent anything else?

> I am not suggesting anything wrong with (minibufferp). What I have in
> mind is that it would be better if there is a mode for the minibuffer,
> so that existing packages can still use *-modes, *-global-modes,
> *-inhibit-modes, etc. to decide whether to enable or disable some
> functionalities. I checked the several packages I mentioned, they
> either compare major-mode with minibuffer-inactive-mode directly, or
> use some *-modes variable that checks the major-mode. Their
> maintainers' life will be easier comparing to the case where only
> (minibufferp) is available and they are forced to make a corner case
> for the minibuffer.

OK, thanks, I understand now.

> > I hope my description in this post is satisfactory.
> Yes, crystal clear!

> > So, a quick summary: (i) the change in the minibuffer's major mode
> > to fundamental-mode was intended; (ii) there may be some problems in
> > some packages because of this; (iii) we aren't yet in agreement on
> > how to proceed with this bug report.

> (i)(ii) agreed.
> (iii), I am mostly in support of removing minibuffer-inactive-mode and
> minibuffer-inactive-mode-map, and give the minibuffer a proper mode.
> This way, the maintainers' life will be easier. Another option is
> still remove minibuffer-inactive-mode and
> minibuffer-inactive-mode-map, but keep minibuffer in fundamental mode.
> What do you think?

After some thought, I think the best thing would be to leave
minibuffer-inactvie-mode as it is, and create a new mode for an active
minibuffer called `minibuffer-mode'.  That would enable minor modes to
specify minibuffer-mode in lists of modes they handle, or don't handle,
as you say.

This shouldn't be too much work.  What do you say?

> Sheng Yang(杨圣), PhD
> Computer Science Department
> University of Maryland, College Park
> E-mail: styang@HIDDEN
> E-mail (old but still used): yangsheng6810@HIDDEN

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 21:58:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 15 17:58:34 2021
Received: from localhost ([127.0.0.1]:37445 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lLvEQ-0002Ol-0L
	for submit <at> debbugs.gnu.org; Mon, 15 Mar 2021 17:58:34 -0400
Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:44259)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <styang@HIDDEN>) id 1lLvEO-0002OX-7y
 for 47150 <at> debbugs.gnu.org; Mon, 15 Mar 2021 17:58:33 -0400
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id 4330027EE;
 Mon, 15 Mar 2021 17:58:26 -0400 (EDT)
Received: from imap2 ([10.202.2.52])
 by compute6.internal (MEProxy); Mon, 15 Mar 2021 17:58:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
 mime-version:message-id:in-reply-to:references:date:from:to:cc
 :subject:content-type; s=fm2; bh=3+e0mahPm1Lp9SK8rxnINJgfySysifQ
 bfFFvuwxdr6w=; b=W2K4u18eJmy244YKkSXZGgYZ730JpxkInXVzQ0/IHW/smrd
 3CbHXnr+XX8AApy7pOlwyRMvITaYXP0hOeKQYZRk+X/tLolaPYqj6U18S7C8eiHp
 26P/LWZ0uAizN3DTpabJYYuJAwrm2psV7oL0AS7WMPaNb2CfX43ntSfTwbFFC0Di
 rSJSHOfdrksXxMZeEhxg29uBbV+pS3VeDIqMOcRmt869YMFhMhqZvNvOUtEToLvs
 8G+mk3WcqXFgdvqFW9P5lpf81qeehjTG33ojcxoOCr5BgkhQDhk4VkKkfSXanHFI
 5M8etm14b4Pkvc1KhZKdKYX5Nf+wYllBdxVH8ow==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3+e0ma
 hPm1Lp9SK8rxnINJgfySysifQbfFFvuwxdr6w=; b=QC4xeuEpxd8NOPm1ZTsUYs
 RhyAm6wYSZE5zQvE8Bjbs7QTFEtuEmkTeDWEjie/dbLTUwUJUyjC5NPSRcU4VJOg
 KGmIv5J1D8GiOgcdQfnSdWwlXubUnqibXs4XtVFClqlujfiPew191z1Z08Hkt1nI
 mYUDlCPHLu3bBYYWDtMkj+mXa6WFZDh0a7OySY5f2t2zUe9eXBhhkAoOpRMNAbjW
 HykX7EVJzz1aV4Nkcl7zY0U1UIvc/65ic0ThkgXJUinZpk6L6zRgWQh6OzCtuXsI
 o5OggsjnuaJkasGbGO6oIlujpFfSxxnc4yalmX3PqVmn7mGjUnf9J2V52DIclajA
 ==
X-ME-Sender: <xms:gdhPYMbj6xEQkE0lxVJvp_qXhYh9Op3sXu8RxoEFy8VFY7W_Ot_KpA>
 <xme:gdhPYHb7kYZfeTZfvj6B850jhbLDCyoIG7SI65CCvhvtWpY7cTH9wUmlUbSHyjtMA
 qYuXbvxJIYtzTP-P2k>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeftddgtdegucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd
 erreerreejnecuhfhrohhmpedfufhhvghnghcujggrnhhgfdcuoehsthihrghnghesfhgr
 shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeehleeutdduffffgeffieelte
 etvdduieehhfevgfdviedvtddtieefieeggeevjeenucevlhhushhtvghrufhiiigvpedt
 necurfgrrhgrmhepmhgrihhlfhhrohhmpehsthihrghnghesfhgrshhtmhgrihhlrdgtoh
 hm
X-ME-Proxy: <xmx:gdhPYG9tPJBUTAWdhH0eEqRbdt_skxwMysuy8WzWBjpNDjm1v15aNA>
 <xmx:gdhPYGq-Qx1rxy1qBkLH__-TxyJEkQRC2TTI9KcYsh1zE0KQ7J1-JA>
 <xmx:gdhPYHoT5wTADgctcg05_4G2w2HaFcrzDJvONdDH2bTCuc5MFjdfhw>
 <xmx:gdhPYBHn0RX7qqyZ9FA1f8oruViLqXq3hlxFb30vBP4qmqEQb14DPw>
Received: by mailuser.nyi.internal (Postfix, from userid 501)
 id 32CEDA00073; Mon, 15 Mar 2021 17:58:25 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@HIDDEN>
In-Reply-To: <YE/SAcvWKTxdVZVb@ACM>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
 <YE/SAcvWKTxdVZVb@ACM>
Date: Mon, 15 Mar 2021 16:58:04 -0500
From: "Sheng Yang" <styang@HIDDEN>
To: "Alan Mackenzie" <acm@HIDDEN>
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Content-Type: multipart/alternative; boundary=7b00dfe34f644f6e8a660dca0fab2ec1
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hi Alan, Thanks for the detailed explanation,
 everything makes
 sense now. I still would like to clarify the following > As you say, there
 is (minibufferp). What is wrong with that? > > That does indeed suggest we
 really want a minibuffer-mode, rather than > just fundamental-mode. But surely,
 the parenthesis pairing w [...] 
 Content analysis details:   (1.8 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (styang[at]fastmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [64.147.123.25 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [64.147.123.25 listed in wl.mailspike.net]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 1.5 FROM_FMBLA_NEWDOM      From domain was registered in last 7 days
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 1.0 FREEMAIL_REPLY         From and body contain different freemails
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.2 (/)

--7b00dfe34f644f6e8a660dca0fab2ec1
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Alan,

Thanks for the detailed explanation, everything makes sense now. I still=
 would like to clarify the following

> As you say, there is (minibufferp).  What is wrong with that?
>=20
> That does indeed suggest we really want a minibuffer-mode, rather than=

> just fundamental-mode.  But surely, the parenthesis pairing will be
> dependant on the sort of text you're typing into the minibuffer, so it=

> can't really be connected with, say, minibuffer-mode.
>=20
> Sorry, I don't understand what you mean, here.  How will the use of
> (minibufferp) prevent anything else?

I am not suggesting anything wrong with (minibufferp). What I have in mi=
nd is that it would be better if there is a mode for the minibuffer, so =
that existing packages can still use *-modes, *-global-modes, *-inhibit-=
modes, etc. to decide whether to enable or disable some functionalities.=
 I checked the several packages I mentioned, they either compare major-m=
ode with minibuffer-inactive-mode directly, or use some *-modes variable=
 that checks the major-mode. Their maintainers' life will be easier comp=
aring to the case where only (minibufferp) is available and they are for=
ced to make a corner case for the minibuffer.

> I hope my description in this post is satisfactory.
Yes, crystal clear!

> So, a quick summary: (i) the change in the minibuffer's major mode to
> fundamental-mode was intended; (ii) there may be some problems in some=

> packages because of this; (iii) we aren't yet in agreement on how to
> proceed with this bug report.

(i)(ii) agreed.
(iii), I am mostly in support of removing minibuffer-inactive-mode and m=
inibuffer-inactive-mode-map, and give the minibuffer a proper mode. This=
 way, the maintainers' life will be easier. Another option is still remo=
ve minibuffer-inactive-mode and minibuffer-inactive-mode-map, but keep m=
inibuffer in fundamental mode. What do you think?


Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: styang@HIDDEN
E-mail (old but still used): yangsheng6810@HIDDEN


--7b00dfe34f644f6e8a660dca0fab2ec1
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi Alan,<br></d=
iv><div><br></div><div>Thanks for the detailed explanation, everything m=
akes sense now. I still would like to clarify the following<br></div><di=
v><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>As you s=
ay, there is (minibufferp).&nbsp; What is wrong with that?<br></div><div=
><br></div><div>That does indeed suggest we really want a minibuffer-mod=
e, rather than<br></div><div>just fundamental-mode.&nbsp; But surely, th=
e parenthesis pairing will be<br></div><div>dependant on the sort of tex=
t you're typing into the minibuffer, so it<br></div><div>can't really be=
 connected with, say, minibuffer-mode.<br></div><div><br></div><div>Sorr=
y, I don't understand what you mean, here.&nbsp; How will the use of<br>=
</div><div>(minibufferp) prevent anything else?<br></div></blockquote><d=
iv><br></div><div>I am not suggesting anything wrong with (minibufferp).=
 What I have in mind is that it would be better if there is a mode for t=
he minibuffer, so that existing packages can still use *-modes, *-global=
-modes, *-inhibit-modes, etc. to decide whether to enable or disable som=
e functionalities. I checked the several packages I mentioned, they eith=
er compare major-mode with minibuffer-inactive-mode directly, or use som=
e *-modes variable that checks the major-mode. Their maintainers' life w=
ill be easier comparing to the case where only (minibufferp) is availabl=
e and they are forced to make a corner case for the minibuffer.<br></div=
><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>I ho=
pe my description in this post is satisfactory.<br></div></blockquote><d=
iv>Yes, crystal clear!<br></div><div><br></div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div>So, a quick summary: (i) the change in the mi=
nibuffer's major mode to<br></div><div>fundamental-mode was intended; (i=
i) there may be some problems in some<br></div><div>packages because of =
this; (iii) we aren't yet in agreement on how to<br></div><div>proceed w=
ith this bug report.<br></div></blockquote><div><br></div><div>(i)(ii) a=
greed.<br></div><div>(iii), I am mostly in support of removing minibuffe=
r-inactive-mode and minibuffer-inactive-mode-map, and give the minibuffe=
r a proper mode. This way, the maintainers' life will be easier. Another=
 option is still remove minibuffer-inactive-mode and minibuffer-inactive=
-mode-map, but keep minibuffer in fundamental mode. What do you think?<b=
r></div><div><br></div><div><br></div><div id=3D"sig97546008"><div class=
=3D"signature">Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD<br></div><div class=3D=
"signature">Computer Science Department<br></div><div class=3D"signature=
">University of Maryland, College Park<br></div><div class=3D"signature"=
>E-mail: <a href=3D"mailto:styang@HIDDEN">styang@HIDDEN</a><=
br></div><div class=3D"signature">E-mail (old but still used): <a href=3D=
"mailto:yangsheng6810@HIDDEN">yangsheng6810@HIDDEN</a><br></div><d=
iv class=3D"signature"><br></div></div><div><br></div></body></html>
--7b00dfe34f644f6e8a660dca0fab2ec1--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 21:30:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 15 17:30:51 2021
Received: from localhost ([127.0.0.1]:37401 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lLunb-0001iD-5y
	for submit <at> debbugs.gnu.org; Mon, 15 Mar 2021 17:30:51 -0400
Received: from colin.muc.de ([193.149.48.1]:34408 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lLunY-0001hz-N2
 for 47150 <at> debbugs.gnu.org; Mon, 15 Mar 2021 17:30:49 -0400
Received: (qmail 83914 invoked by uid 3782); 15 Mar 2021 21:30:42 -0000
Received: from acm.muc.de (p4fe15b5d.dip0.t-ipconnect.de [79.225.91.93])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 15 Mar 2021 22:30:41 +0100
Received: (qmail 20021 invoked by uid 1000); 15 Mar 2021 21:30:41 -0000
Date: Mon, 15 Mar 2021 21:30:41 +0000
To: Sheng Yang <styang@HIDDEN>
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Message-ID: <YE/SAcvWKTxdVZVb@ACM>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
 <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Sheng.

On Mon, Mar 15, 2021 at 13:15:02 -0500, Sheng Yang wrote:
> Hi Alan,

> On Mon, Mar 15, 2021, at 02:59, Alan Mackenzie wrote:
> > Why is fundamental-mode incorrect for a minibuffer, and what should the
> > major mode be instead?

> > What problems does fundamental-mode give you in a minibuffer?

> The word "correct" here has a two-fold meaning, 1) the design itself
> is good (whether it is good can be discussed), 2) the behavior is as
> intended.

> For the first point, I think before the offending commit, the
> major-mode of a minibuffer is minibuffer-inactive-mode. I am not aware
> of the reasons behind the decision, but it seems a reasonable choice.
> We do not need a reason to keep the existing decision, but we do need
> an explanation for a decision to change it to fundamental-mode.
> Anyway, I would give a few points for keeping the major-mode as
> minibuffer-inactive-mode: 

OK, I'll start with 2).  Up to Emacs-27, a minibuffer got created in
fundamental-mode, got used, then after the user typed RET or C-g, was
put into minibuffer-inactive-mode.  When the minibuffer got used a
second time, it got left in minibuffer-inactive-mode.  This was a bug,
though not a serious one.  The minibuffer then stayed in that mode until
Emacs shutdown.

minibuffer-inactive-mode: the critical thing here is "inactive", which
means "doing nothing", or "not in use", or even "sleeping".  The
opposite word is "active".  From its name, this major mode was never
intended for use in active minibuffers, but somehow nobody noticed that
the buffer never got shifted out of minibuffer-inactive-mode when it
came to be used again.

I've been fixing things in minibuf.c recently, and when I discovered
this anomaly, I fixed it, so that an active minibuffer now runs in
fundamental-mode, as originally intended.  I did wonder why there was no
"minibuffer-mode".  But it was clear from the code that whoever wrote it
intended minibuffers to use fundamental-mode whilst active.

> 1. Packages depend on it, to name a few: lispy, smartparens, and
> telega.

The maintainers of those packages are probably unhappy about
minibuffer-inactive-mode.  In any case, it doesn't work on the first use
of a minibuffer (see above).

> 2. We do need something to check that we are in the minibuffer, and
> apply something.

As you say, there is (minibufferp).  What is wrong with that?

> For my case, I want automatic paren pairing and editing in
> eval-expression.

That does indeed suggest we really want a minibuffer-mode, rather than
just fundamental-mode.  But surely, the parenthesis pairing will be
dependant on the sort of text you're typing into the minibuffer, so it
can't really be connected with, say, minibuffer-mode.

> Plus we also need a keymap for it, which is
> minibuffer-inactive-mode-map.

No.  That keymap is very low functionality, and almost useless, as it's
intended to be.  The idea is that while a minibuffer is inactive, a user
can't do any damage with it.

When a (low-level) minibuffer function is called, a keymap is an
argument to that function, and that gets used instead.

> We can use (minibufferp), but this will prevent the existing use of
> *-global-modes in packages to decide whether to enable in the
> minibuffer.

Sorry, I don't understand what you mean, here.  How will the use of
(minibufferp) prevent anything else?

> 3. The choice of minibuffer-inactive-mode is written in elisp manual.
> I believe any changes that breaks backward compatibility needs a sound
> reason.

minibuffer-inactive-mode is described in the elisp manual as being for
INACTIVE minibuffers, i.e. those that aren't currently in use.  It was a
bug that that major mode was still in force for active minibuffers
(apart from their first use in an Emacs session).

> If you are aware of a thread on an explanation for the decision to
> switch to fundamantal-mode, please send me a pointer.

I hope my description in this post is satisfactory.

> For the second point, the new behavior seems not intended according to
> the commit message of the offending commit. Here is the whole commit
> message of 636ef445af:

> >     With minibuffer-follows-selected-frame `hybrid', preserve recursive Mbuffers

> >     ...when enable-recursive-minibuffers is non-nil, and several minibuffers are
> >     activated from different frames.  Also set the major mode of a reused active
> >     minibuffer to `fundamental-mode' - up till now it's been
> >     minibuffer-inactive-mode.

> >     * src/minibuf.c (read_minibuf): with the indicated settings of variables,
> >     "stack up" all containing minibuffers on the mini-window of the current
> >     frame.  Delete another, now superfluous such stacking up.
> >     (set_minibuffer_mode): New function.
> >     (get_minibuffer): Call the above new function (twice), in place of inline
> >     code, ensuring active minibuffers are never left in minibuffer-inactive-mode.

It was me that made that commit.  The change to the major mode was fully
intended.  I thought the description of the change was adequate.

> At the point of reporting the bug, I thought the change of major mode
> only applies when you have minibuffer-follows-selected-frame set to
> `hybrid'.

Sorry, that wasn't the intended meaning.  The change in major mode is
regardless of the setting of minibuffer-follows-selected-frame.

> I am less sure about this understanding now. Currently, from
> what I understand, it is only when we reuse an active minibuffer when
> we have fundamental-mode set as major mode. However, with a single
> buffer, and the first interactive usage of the minibuffer by pressing
> M-:, the major-mode is reported as fundamental-mode, instead of
> minibuffer-inactive-mode, as in Emacs 27.1. What does a "reuse" means
> here?

"Reuse", probably better written as "re-use", just means to use again.

> I am not sure I understand the differences between an active and
> inactive minibuffer, and the elisp manual does not really help me
> much.

"Active" means "in use", "inactive" means "not in use", in this context.

> It seems to me the minibuffer is always inactive? I tried M-x,
> M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1.  Is this
> a mistake and the offending commit was trying to fix this
> inconsistency?

Very much so!

> > > 3. Press M-; to call eval-expression, which will report that the
> > > major-mode is fundamental-mode

> Typo fix: to call eval-expression, the key-binding is `M-:' instead of
> `M-:'

So, a quick summary: (i) the change in the minibuffer's major mode to
fundamental-mode was intended; (ii) there may be some problems in some
packages because of this; (iii) we aren't yet in agreement on how to
proceed with this bug report.

> Sheng Yang(杨圣), PhD
> Computer Science Department
> University of Maryland, College Park
> E-mail: styang@HIDDEN
> E-mail (old but still used): yangsheng6810@HIDDEN

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 18:15:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 15 14:15:35 2021
Received: from localhost ([127.0.0.1]:36976 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lLrkc-0004zR-E1
	for submit <at> debbugs.gnu.org; Mon, 15 Mar 2021 14:15:35 -0400
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:47431)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <styang@HIDDEN>) id 1lLrkZ-0004zC-Kc
 for 47150 <at> debbugs.gnu.org; Mon, 15 Mar 2021 14:15:32 -0400
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id E876F2754;
 Mon, 15 Mar 2021 14:15:24 -0400 (EDT)
Received: from imap2 ([10.202.2.52])
 by compute6.internal (MEProxy); Mon, 15 Mar 2021 14:15:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
 mime-version:message-id:in-reply-to:references:date:from:to:cc
 :subject:content-type; s=fm2; bh=Ol6qxcGayOyCw9+GdhIKlcyg7VS1fUv
 1K6QwRlWpfgs=; b=mWPXEtDdKeLixDwdtTlc65VePfOt/ko7GhRGizrc5d+O36D
 tc3hY8DfLvgX3WOsmgNzkumN3FCotFJ2/YxSWnmUJ1FeHUEu8Z+4fLZPgFWSpe6I
 l7v/Qn31yjaJ5Z3Hzr5OZqf6l81GrIuYY/oCgwFeE2uYjLEUDcntu9xFkgnmSK8r
 oFy5vHBF/iLp1h8v2vABRCQ3bP3AfE4RaSNkhVu+wXLruNpF2FD9U0cnzWwZRUQ6
 yOC8Mb+qbr4nsj2eo3yByh9PYdENTU347rX542g9Oq0CROGJRe1Ir78bi5cj7a7j
 hwqEbjGEqgawJsxHRFVZYqAYRIel0tO4yVKKKQg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ol6qxc
 GayOyCw9+GdhIKlcyg7VS1fUv1K6QwRlWpfgs=; b=Vy+L64YN2+z7koJfDpYEiO
 pJ9DdF6H/zIU2vwvIUxdy0pTVlBlCqz4JhyyaDIK+mgy2psZR+wGsdSr4vf+A7Cs
 909iHq1Q1JLO+Q2G8uzKt036BKw8vhy/5cyCtYP2xmk1QLNTFHMj1QVdf4LZI4aU
 J55s37L1IVbleS3AJ4JU+VWT+hl2F3/UjkHNO+jX8WbXAuSGBtgxi5mNmnV7FxQd
 tNpHd5Ed/ZNMphru0I1wZWMM67bBwo4R6/hn2lCoby9RAbxqo7dRUaY7j79lFOaK
 tn0b/TzfzKvmfPTzRiwzxWSc0QBUuZIp/FIFlTKjl7F23h1W5veehdL5tVfS00dw
 ==
X-ME-Sender: <xms:PKRPYL0fhs3r2N8ZtJjpmFpRNcZMA84zRN8j-PhTAKI4ELCjMH3kFw>
 <xme:PKRPYKFt0XKZdp3GWcHhsbGAjgUZeV3XLuwUr_kCIAmEHDDaMTAP8DD_JlFY3kxrQ
 bKqIPza3r7-gpGhBnA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvledgudduudcutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg
 dtreerreerjeenucfhrhhomhepfdfuhhgvnhhgucgjrghnghdfuceoshhthigrnhhgsehf
 rghsthhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepheeluedtudffffegffeile
 ettedvudeihefhvefgvdeivddttdeifeeigeegveejnecuvehluhhsthgvrhfuihiivgep
 udenucfrrghrrghmpehmrghilhhfrhhomhepshhthigrnhhgsehfrghsthhmrghilhdrtg
 homh
X-ME-Proxy: <xmx:PKRPYL6rdrEBVWfvqk16a6rxyFDoN1weIhlmvO3KeFQZ71fkNOfx0w>
 <xmx:PKRPYA1A34mCnLRkflTqDqgqXPQgyfvAK5k1nuIq5dClJ5d2-DxspA>
 <xmx:PKRPYOG32dUstI_kmtnNyexW-d_UUUgY7q8o24AJ3doJgojkjPsD4A>
 <xmx:PKRPYJxTHydj8ae5aOn4eNQHdvjyE7_X-ZljqabpyVUi28dy-Jgvfw>
Received: by mailuser.nyi.internal (Postfix, from userid 501)
 id EE17DA00073; Mon, 15 Mar 2021 14:15:23 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@HIDDEN>
In-Reply-To: <YE8T/2YY6ZMxCRCl@ACM>
References: <877dm9nsii.fsf@HIDDEN> <YE8T/2YY6ZMxCRCl@ACM>
Date: Mon, 15 Mar 2021 13:15:02 -0500
From: "Sheng Yang" <styang@HIDDEN>
To: "Alan Mackenzie" <acm@HIDDEN>
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Content-Type: multipart/alternative; boundary=9d45e26453b1409292122bd5e766879b
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hi Alan, On Mon, Mar 15, 2021, at 02:59,
 Alan Mackenzie wrote:
 > Why is fundamental-mode incorrect for a minibuffer, and what should the
 > major mode be instead? > > What problems does fundamental-mode give yo
 [...] Content analysis details:   (1.8 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [64.147.123.21 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [64.147.123.21 listed in wl.mailspike.net]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (styang[at]fastmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 HTML_MESSAGE           BODY: HTML included in message
 1.5 FROM_FMBLA_NEWDOM      From domain was registered in last 7 days
 1.0 FREEMAIL_REPLY         From and body contain different freemails
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.2 (/)

--9d45e26453b1409292122bd5e766879b
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Alan,

On Mon, Mar 15, 2021, at 02:59, Alan Mackenzie wrote:
> Why is fundamental-mode incorrect for a minibuffer, and what should th=
e
> major mode be instead?
>=20
> What problems does fundamental-mode give you in a minibuffer?

The word "correct" here has a two-fold meaning, 1) the design itself is =
good (whether it is good can be discussed), 2) the behavior is as intend=
ed.

For the first point, I think before the offending commit, the major-mode=
 of a minibuffer is minibuffer-inactive-mode. I am not aware of the reas=
ons behind the decision, but it seems a reasonable choice. We do not nee=
d a reason to keep the existing decision, but we do need an explanation =
for a decision to change it to fundamental-mode. Anyway, I would give a =
few points for keeping the major-mode as minibuffer-inactive-mode:=20
1. Packages depend on it, to name a few: lispy, smartparens, and telega.=

2. We do need something to check that we are in the minibuffer, and appl=
y something. For my case, I want automatic paren pairing and editing in =
eval-expression. Plus we also need a keymap for it, which is minibuffer-=
inative-mode-map. We can use (minibufferp), but this will prevent the ex=
isting use of *-global-modes in packages to decide whether to enable in =
the minibuffer.
3. The choice of minibuffer-inactive-mode is written in elisp manual. I =
believe any changes that breaks backward compatibility needs a sound rea=
son.

If you are aware of a thread on an explanation for the decision to switc=
h to fundamantal-mode, please send me a pointer.

For the second point, the new behavior seems not intended according to t=
he commit message of the offending commit. Here is the whole commit mess=
age of 636ef445af:
>     With minibuffer-follows-selected-frame `hybrid', preserve recursiv=
e Mbuffers
>   =20
>     ...when enable-recursive-minibuffers is non-nil, and several minib=
uffers are
>     activated from different frames.  Also set the major mode of a reu=
sed active
>     minibuffer to `fundamental-mode' - up till now it's been
>     minibuffer-inactive-mode.
>   =20
>     * src/minibuf.c (read_minibuf): with the indicated settings of var=
iables,
>     "stack up" all containing minibuffers on the mini-window of the cu=
rrent
>     frame.  Delete another, now superfluous such stacking up.
>     (set_minibuffer_mode): New function.
>     (get_minibuffer): Call the above new function (twice), in place of=
 inline
>     code, ensuring active minibuffers are never left in minibuffer-ina=
ctive-mode.

At the point of reporting the bug, I thought the change of major mode on=
ly applies when you have minibuffer-follows-selected-frame set to `hybir=
d'. I am less sure about this understanding now. Currently, from what I =
understand, it is only when we reuse an active minibuffer when we have f=
undamental-mode set as major mode. However, with a single buffer, and th=
e first interactive usage of the minibuffer by pressing M-:, the major-m=
ode is reported as fundamental-mode, instead of minibuffer-inactive-mode=
, as in Emacs 27.1. What does a "reuse" means here?

I am not sure I understand the differences between an active and inactiv=
e minibuffer, and the elisp manual does not really help me much. It seem=
s to me the minibuffer is alwals inactive? I tried M-x, M-!, M-:, all re=
ports minibuffer-inactive-mode in Emacs 27.1.  Is this a mistake and the=
 offending commit was trying to fix this inconsistency?

> > 3. Press M-; to call eval-expression, which will report that the maj=
or-mode is fundamental-mode

Typo fix: to call eval-expression, the key-binding is `M-:' instead of `=
M-:'

Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: styang@HIDDEN
E-mail (old but still used): yangsheng6810@HIDDEN


--9d45e26453b1409292122bd5e766879b
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi Alan,<br></d=
iv><div><br></div><div>On Mon, Mar 15, 2021, at 02:59, Alan Mackenzie wr=
ote:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Why is=
 fundamental-mode incorrect for a minibuffer, and what should the<br></d=
iv><div>major mode be instead?<br></div><div><br></div><div>What problem=
s does fundamental-mode give you in a minibuffer?<br></div></blockquote>=
<div><br></div><div>The word "correct" here has a two-fold meaning, 1) t=
he design itself is good (whether it is good can be discussed), 2) the b=
ehavior is as intended.<br></div><div><br></div><div>For the first point=
, I think before the offending commit, the major-mode of a minibuffer is=
 minibuffer-inactive-mode. I am not aware of the reasons behind the deci=
sion, but it seems a reasonable choice. We do not need a reason to keep =
the existing decision, but we do need an explanation for a decision to c=
hange it to fundamental-mode. Anyway, I would give a few points for keep=
ing the major-mode as minibuffer-inactive-mode: <br></div><div>1. Packag=
es depend on it, to name a few: lispy, smartparens, and telega.<br></div=
><div>2. We do need something to check that we are in the minibuffer, an=
d apply something. For my case, I want automatic paren pairing and editi=
ng in eval-expression. Plus we also need a keymap for it, which is minib=
uffer-inative-mode-map. We can use (minibufferp), but this will prevent =
the existing use of *-global-modes in packages to decide whether to enab=
le in the minibuffer.<br></div><div>3. The choice of minibuffer-inactive=
-mode is written in elisp manual. I believe any changes that breaks back=
ward compatibility needs a sound reason.<br></div><div><br></div><div>If=
 you are aware of a thread on an explanation for the decision to switch =
to fundamantal-mode, please send me a pointer.<br></div><div><br></div><=
div>For the second point, the new behavior seems not intended according =
to the commit message of the offending commit. Here is the whole commit =
message of 636ef445af:<br></div><blockquote type=3D"cite"><div>&nbsp;&nb=
sp;&nbsp; With minibuffer-follows-selected-frame `hybrid', preserve recu=
rsive Mbuffers<br></div><div>&nbsp;&nbsp;&nbsp;<br></div><div>&nbsp;&nbs=
p;&nbsp; ...when enable-recursive-minibuffers is non-nil, and several mi=
nibuffers are<br></div><div>&nbsp;&nbsp;&nbsp; activated from different =
frames.&nbsp; Also set the major mode of a reused active<br></div><div>&=
nbsp;&nbsp;&nbsp; minibuffer to `fundamental-mode' - up till now it's be=
en<br></div><div>&nbsp;&nbsp;&nbsp; minibuffer-inactive-mode.<br></div><=
div>&nbsp;&nbsp;&nbsp;<br></div><div>&nbsp;&nbsp;&nbsp; * src/minibuf.c =
(read_minibuf): with the indicated settings of variables,<br></div><div>=
&nbsp;&nbsp;&nbsp; "stack up" all containing minibuffers on the mini-win=
dow of the current<br></div><div>&nbsp;&nbsp;&nbsp; frame.&nbsp; Delete =
another, now superfluous such stacking up.<br></div><div>&nbsp;&nbsp;&nb=
sp; (set_minibuffer_mode): New function.<br></div><div>&nbsp;&nbsp;&nbsp=
; (get_minibuffer): Call the above new function (twice), in place of inl=
ine<br></div><div>&nbsp;&nbsp;&nbsp; code, ensuring active minibuffers a=
re never left in minibuffer-inactive-mode.<br></div></blockquote><div></=
div><div><br></div><div>At the point of reporting the bug, I thought the=
 change of major mode only applies when you have minibuffer-follows-sele=
cted-frame set to `hybird'. I am less sure about this understanding now.=
 Currently, from what I understand, it is only when we reuse an active m=
inibuffer when we have fundamental-mode set as major mode. However, with=
 a single buffer, and the first interactive usage of the minibuffer by p=
ressing M-:, the major-mode is reported as fundamental-mode, instead of =
minibuffer-inactive-mode, as in Emacs 27.1. What does a "reuse" means he=
re?<br></div><div><br></div><div>I am not sure I understand the differen=
ces between an active and inactive minibuffer, and the elisp manual does=
 not really help me much. It seems to me the minibuffer is alwals inacti=
ve? I tried M-x, M-!, M-:, all reports minibuffer-inactive-mode in Emacs=
 27.1.&nbsp; Is this a mistake and the offending commit was trying to fi=
x this inconsistency?<br></div><div><br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>&gt; 3. Press M-; to call eval-expression, whi=
ch will report that the major-mode is fundamental-mode<br></div></blockq=
uote><div id=3D"sig97546008"><div class=3D"signature"><br></div><div cla=
ss=3D"signature">Typo fix: to call eval-expression, the key-binding is `=
M-:' instead of `M-:'<br></div><div class=3D"signature"><br></div><div c=
lass=3D"signature">Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD<br></div><div cla=
ss=3D"signature">Computer Science Department<br></div><div class=3D"sign=
ature">University of Maryland, College Park<br></div><div class=3D"signa=
ture">E-mail: <a href=3D"mailto:styang@HIDDEN">styang@HIDDEN=
</a><br></div><div class=3D"signature">E-mail (old but still used): <a h=
ref=3D"mailto:yangsheng6810@HIDDEN">yangsheng6810@HIDDEN</a><br></=
div><div class=3D"signature"><br></div></div><div><br></div></body></htm=
l>
--9d45e26453b1409292122bd5e766879b--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 08:00:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 15 04:00:10 2021
Received: from localhost ([127.0.0.1]:34807 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lLi93-0004Wt-W4
	for submit <at> debbugs.gnu.org; Mon, 15 Mar 2021 04:00:10 -0400
Received: from colin.muc.de ([193.149.48.1]:12401 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1lLi91-0004Uq-HV
 for 47150 <at> debbugs.gnu.org; Mon, 15 Mar 2021 04:00:08 -0400
Received: (qmail 54367 invoked by uid 3782); 15 Mar 2021 08:00:00 -0000
Received: from acm.muc.de (p4fe15b5d.dip0.t-ipconnect.de [79.225.91.93])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 15 Mar 2021 09:00:00 +0100
Received: (qmail 5396 invoked by uid 1000); 15 Mar 2021 07:59:59 -0000
Date: Mon, 15 Mar 2021 07:59:59 +0000
To: styang@HIDDEN
Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer
Message-ID: <YE8T/2YY6ZMxCRCl@ACM>
References: <877dm9nsii.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <877dm9nsii.fsf@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47150
Cc: 47150 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Sheng.

On Sun, Mar 14, 2021 at 19:57:09 -0500, styang@HIDDEN wrote:
> The major-mode in the minibuffer is incorrectly set to
> fundamental-mode, even when it is the first one.

Why is fundamental-mode incorrect for a minibuffer, and what should the
major mode be instead?

What problems does fundamental-mode give you in a minibuffer?

> Reproduce with the following steps:

> 1. emacs -q
> 2. Eval the following:

> (defun report-major-mode ()
>   (message "mini-buffer major-mode is %s" major-mode))
> (add-hook 'minibuffer-setup-hook 'report-major-mode)

> 3. Press M-; to call eval-expression, which will report that the major-mode is fundamental-mode


> The offending commit is 636ef445af.


> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.26, cairo version 1.17.4)
>  of 2021-03-12 built on Desktop
> Repository revision: 592fabdc7f8d9c52c931843a153fdac67a302c30
> Repository branch: makepkg
> Windowing system distributor 'System Description: Arch Linux

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at 47150 <at> debbugs.gnu.org:


Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 01:02:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 14 21:02:38 2021
Received: from localhost ([127.0.0.1]:34552 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lLbd0-0000Yq-5P
	for submit <at> debbugs.gnu.org; Sun, 14 Mar 2021 21:02:38 -0400
Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:40245)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <styang@HIDDEN>) id 1lLbcx-0000Yd-Uk
 for 47150 <at> debbugs.gnu.org; Sun, 14 Mar 2021 21:02:36 -0400
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id C383129C2;
 Sun, 14 Mar 2021 21:02:29 -0400 (EDT)
Received: from imap2 ([10.202.2.52])
 by compute6.internal (MEProxy); Sun, 14 Mar 2021 21:02:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
 mime-version:message-id:date:from:to:cc:subject:content-type; s=
 fm2; bh=ao7imPTKrOduSqanXS8WIhgMRwPMHVpEoZuOw8WY7lc=; b=VKszraKT
 H854oPh/SmGomd+V4MbafN89n4nL0ikmPAxtQSFSDOIFX8pCX9YY7NBLz3RQ17D2
 HzNT0ubcqPploVqw13woPsGGrpdvdWD6vZOCnwNrExg+tMda/sPI2gVmmnkwIOk3
 5+Qj0zAXDb06Y9dEZVhwHfp74kSj/fXMEqaY1zwwIU8OnnSiO+Wk7EICojjhmwOK
 ira8f1dDPcdEILjB2oY189MDb6wDcPz7oMjwvZO/FWvL5aBo+kHb+BfEBXGIHi1r
 JW/ZsctwYejbc/36v1ItHb/KSl5JAd+/ZXQsN59IOgEMVOOBn5mIUE0y2sqtPSz2
 dygcSp+CbSVhuQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:message-id
 :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender
 :x-me-sender:x-sasl-enc; s=fm2; bh=ao7imPTKrOduSqanXS8WIhgMRwPMH
 VpEoZuOw8WY7lc=; b=tD6QIiKxXxsbcmJERwHIDOqn8wVs2UkdU5IGN8QOt0/bF
 dH/eBa6JGNPeu+9scI0cPTDut5lSDmIZiXLPVr5B+j85UegLWEetMilVuLIbyJ86
 RFINhr1Q7oeZSmYtz32w6DG/dMcHK/RzzLZgikl38PE8x1ABWxOHI+wzv9GApQn+
 Q5RL2j/TvT2l0mDIC+5d9RvSZEy26/ssLl+6Tk1byaS4jy3zhHIXNe7I/lFIVmFE
 c4r3Ynh5FQkzBTwQprV9LNwKENvjb5YTY/pF4VLl9Z5Ovcj768gdG4B512cD+9+1
 x0L7+W4Hq2Zj3Nlba9mlIO9vJavM70q+kjZGnjXEg==
X-ME-Sender: <xms:JbJOYE8u4Bhcte9zEttccT6ABza5WBbxOMx0928eBjhjiAH5Ex_h7Q>
 <xme:JbJOYMvN2HsaiZiYK7PhvVa8UsNUG7CrPpner9b-wHTTdSyYDeIIHCAmAJHZzZEO7
 Vnl-epcspqq60QgukY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvkedgvdekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre
 erreejnecuhfhrohhmpedfufhhvghnghcujggrnhhgfdcuoehsthihrghnghesfhgrshht
 mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeejvedvheekudeggfduhfduieeile
 dvfedvkeehleduuefhleeugeehtdekueetueenucevlhhushhtvghrufhiiigvpedtnecu
 rfgrrhgrmhepmhgrihhlfhhrohhmpehsthihrghnghesfhgrshhtmhgrihhlrdgtohhm
X-ME-Proxy: <xmx:JbJOYKBZuDwYkEMdBebEExMCS7qe38C7LU4AAeG05hRSCJyc1Ue1wg>
 <xmx:JbJOYEdVZx_lRhx8ZQqeivB9V2h7Lm-3C7p1M6dcl328Q-vhjdb6cQ>
 <xmx:JbJOYJPdVKEKv-KDyAsF87JeysgGzNUWwoFudMVHxJy79c6dGelTVA>
 <xmx:JbJOYAbP3uElShvqBDDonrI4FJACA2eTGoXztJ-lzuDdlQ6vZbXA7g>
Received: by mailuser.nyi.internal (Postfix, from userid 501)
 id 057A2A00073; Sun, 14 Mar 2021 21:02:29 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <6f08da77-9cf3-46f7-9f6c-d351ace99f4c@HIDDEN>
Date: Sun, 14 Mar 2021 20:02:08 -0500
From: "Sheng Yang" <styang@HIDDEN>
To: 47150 <at> debbugs.gnu.org
Subject: Emacs bug#47150 28.0.50; Incorrect major-mode in minibuffer
Content-Type: multipart/alternative; boundary=7eda725d5f6849da9ac906c53292a0b0
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 47150
Cc: Alan Mackenzie <acm@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

--7eda725d5f6849da9ac906c53292a0b0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

CCing the author of the offending commit 636ef445af.

Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: styang@HIDDEN
E-mail (old but still used): yangsheng6810@HIDDEN


--7eda725d5f6849da9ac906c53292a0b0
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>CCing the autho=
r of the offending commit 636ef445af.</div><div><br></div><div id=3D"sig=
97546008"><div class=3D"signature">Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD<b=
r></div><div class=3D"signature">Computer Science Department<br></div><d=
iv class=3D"signature">University of Maryland, College Park<br></div><di=
v class=3D"signature">E-mail: <a href=3D"mailto:styang@HIDDEN">sty=
ang@HIDDEN</a><br></div><div class=3D"signature">E-mail (old but s=
till used): <a href=3D"mailto:yangsheng6810@HIDDEN">yangsheng6810@gma=
il.com</a><br></div><div class=3D"signature"><br></div></div><div><br></=
div></body></html>
--7eda725d5f6849da9ac906c53292a0b0--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 15 Mar 2021 00:57:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 14 20:57:29 2021
Received: from localhost ([127.0.0.1]:34534 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lLbY1-0000Nq-6d
	for submit <at> debbugs.gnu.org; Sun, 14 Mar 2021 20:57:29 -0400
Received: from lists.gnu.org ([209.51.188.17]:51438)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <styang@HIDDEN>) id 1lLbXz-0000Ni-BH
 for submit <at> debbugs.gnu.org; Sun, 14 Mar 2021 20:57:27 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:56114)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <styang@HIDDEN>)
 id 1lLbXy-0006Cn-UB
 for bug-gnu-emacs@HIDDEN; Sun, 14 Mar 2021 20:57:27 -0400
Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:36621)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <styang@HIDDEN>)
 id 1lLbXv-0000xD-V9
 for bug-gnu-emacs@HIDDEN; Sun, 14 Mar 2021 20:57:26 -0400
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id 02E322917
 for <bug-gnu-emacs@HIDDEN>; Sun, 14 Mar 2021 20:57:20 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute6.internal (MEProxy); Sun, 14 Mar 2021 20:57:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
 from:to:subject:date:message-id:mime-version:content-type; s=
 fm2; bh=kefw6pvHlOy0vqdZmDZkmWjKDWWASgoZhmpScLOWF38=; b=FDsFqsOL
 mvDNfGPQDR2b2FFK3ZKCo755johr6gztE9WoL/mTnqbeFpkzoyMeYwlkVWkoxzsh
 wC07Ka8rGRjN5zFFBpPJ5QuaKrGG+OZB+Brh+paEgG7hxSRN8/5Qwow8uf4nyNhv
 P9Ynd0ZoG++CKKAqJwLKCHyuk43rbkmW0OmmOH6PWU6bov6hbqX7Qes/uxbWcoqr
 PvbVHgOC7MWctWKWaYBwMxu6embFJDcqdNYR837oYy5LFOfHPGQyPBiRKGep8Wxf
 FKiTps1Ap0orCqhT3HcVwT5/VofMHdkvPjdNAA9HYEj6qo9YBbqCG2O9SVlaFsXx
 DUAIC/FEFGZIpg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=content-type:date:from:message-id
 :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender
 :x-me-sender:x-sasl-enc; s=fm2; bh=kefw6pvHlOy0vqdZmDZkmWjKDWWAS
 goZhmpScLOWF38=; b=L7t7p6V+oKCQd7dGV+FmoAS7/8KbpRrhg6zg2nJ1lE3is
 4Zk4SRRnHJ8txWvmqJpah8mI73ol8RUC/XGJ1dz/90rSpZfn5XNdC6vINI1Yciue
 qjOW/+2h+PcgC0rE5Qpe3F/ltMvtFj6RqbRMo3r9wKg2RUE9VImt97gfyzvzghQU
 UNBNXQrUveI3HzfuWs8Of1IrPphReoES0HDWc3aro7rPMdyp9hfaYqF9rlEffFMs
 9gjkeCwdqFKQXdhh4k0xFi1dKShYxjajHzF38XzO+3UrkXVRW72QFNWMAUDIZwNc
 9OvXASRgyyjnvojNwp181kCVOOWSxeWhhM6hxl+4Q==
X-ME-Sender: <xms:8LBOYGOWjI-lOW8hmUcqlk9cKC6hSb44ZrH3FbCMOedYRo2jAZeu5A>
 <xme:8LBOYE8WMzO80JvXXftF6gr9QePPy_jnZfbAP1F-RRmXnwth5tRZGk1MbjU8aNsri
 phnsld7MRpcPRbxqHU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvkedgvdejucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkgggtsehttdertddttd
 dtnecuhfhrohhmpehsthihrghnghesfhgrshhtmhgrihhlrdgtohhmnecuggftrfgrthht
 vghrnhepveehvdffvdejteehhfdthfegfeejgfffgeeuvdeivdevvedvfeduhfdvfefhff
 ehnecukfhppeejfedrvddtkedrudegledrkeefnecuvehluhhsthgvrhfuihiivgeptden
 ucfrrghrrghmpehmrghilhhfrhhomhepshhthigrnhhgsehfrghsthhmrghilhdrtghomh
X-ME-Proxy: <xmx:8LBOYNTR_7w4YvZqglxzLMM2wm5oHfX6jyZCuZoRweT1aBcuYl7_DQ>
 <xmx:8LBOYGs7xNuGlwKVX8ZVOl6ufF3UlCfQWanLsVrfiSbjjgiaJXw8iQ>
 <xmx:8LBOYOcy16y-WnE0T3DjOR1PHnAd6oVNC-JSJeMzP5LTYgNgI1J8TA>
 <xmx:8LBOYIpKJpj3-_dVGqrqFZhcvX4NMH32EOckn4hPe0RoSNnH4W6whg>
Received: from localhost (c-73-208-149-83.hsd1.il.comcast.net [73.208.149.83])
 by mail.messagingengine.com (Postfix) with ESMTPA id E47EB240054
 for <bug-gnu-emacs@HIDDEN>; Sun, 14 Mar 2021 20:57:19 -0400 (EDT)
From: styang@HIDDEN
To: bug-gnu-emacs@HIDDEN
Subject: 28.0.50; Incorrect major-mode in minibuffer
Date: Sun, 14 Mar 2021 19:57:09 -0500
Message-ID: <877dm9nsii.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=64.147.123.20; envelope-from=styang@HIDDEN;
 helo=wout4-smtp.messagingengine.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -0.2 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.7 (--)

The major-mode in the minibuffer is incorrectly set to fundamental-mode, even when it is the first one.  Reproduce with the following steps:

1. emacs -q
2. Eval the following:

(defun report-major-mode ()
  (message "mini-buffer major-mode is %s" major-mode))
(add-hook 'minibuffer-setup-hook 'report-major-mode)

3. Press M-; to call eval-expression, which will report that the major-mode is fundamental-mode


The offending commit is 636ef445af.


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.26, cairo version 1.17.4)
 of 2021-03-12 built on Desktop
Repository revision: 592fabdc7f8d9c52c931843a153fdac67a302c30
Repository branch: makepkg
Windowing system distributor 'System Description: Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-modules --without-gconf --without-gsettings
 --with-native-compilation --with-pgtk --with-x-toolkit=gtk3
 --without-xaw3d --without-m17n-flt --with-cairo --with-xwidgets
 --without-compress-install 'CFLAGS=-march=x86-64 -mtune=generic -O2
 -pipe -fno-plt -g -fuse-ld=gold' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM XWIDGETS GTK3
ZLIB

Important settings:
  value of $LC_CTYPE: zh_CN.UTF-8
  value of $LANG: zh_CN.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra
help-mode seq byte-opt gv cl-loaddefs cl-lib bytecomp byte-compile cconv
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils china-util
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/pgtk-win pgtk-win term/common-win tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame minibuffer
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese composite
charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev
obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify dynamic-setting font-render-setting
cairo move-toolbar gtk x-toolkit pgtk lcms2 multi-tty
make-network-process nativecomp emacs)

Memory information:
((conses 16 86740 7633)
 (symbols 48 7951 1)
 (strings 32 21797 2724)
 (string-bytes 1 749467)
 (vectors 16 16994)
 (vector-slots 8 376872 18158)
 (floats 8 31 79)
 (intervals 56 277 0)
 (buffers 992 14))




Acknowledgement sent to styang@HIDDEN:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#47150; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 18 Apr 2021 11:30:02 UTC

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