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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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>> 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. What's more, I am now<br>=
</div><div>convinced he is right. ;-)<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. 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.=
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>> Sheng Yan=
g(=E6=9D=A8=E5=9C=A3), PhD<br></div><div>> Computer Science Departmen=
t<br></div><div>> University of Maryland, College Park<br></div><div>=
> E-mail: <a href=3D"mailto:styang%40fastmail.com">styang@fastma=
il.com</a><br></div><div>> E-mail (old but still used): <a href=3D=
"mailto:yangsheng6810%40gmail.com">yangsheng6810@HIDDEN</a><br></div>=
<div><br></div><div>-- <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--
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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>>=
> Can I ask what's wrong with what I suggested: One mode, not two; j=
ust<br></div><div>> > change the name and provide a helpful doc-st=
ring that covers both<br></div><div>> > active and inactive?<br></=
div><div>> <br></div><div>> What's the benefit? 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.... We already have the former<br></div><=
div>part. 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=
? 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. 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--
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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.]
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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'.
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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.)
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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.)
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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.
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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==
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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). 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. 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. 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--
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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> &nb=
sp; With minibuffer-follows-selected-frame `hybrid', preserve recu=
rsive Mbuffers<br></div><div> <br></div><div> &nbs=
p; ...when enable-recursive-minibuffers is non-nil, and several mi=
nibuffers are<br></div><div> activated from different =
frames. Also set the major mode of a reused active<br></div><div>&=
nbsp; minibuffer to `fundamental-mode' - up till now it's be=
en<br></div><div> minibuffer-inactive-mode.<br></div><=
div> <br></div><div> * src/minibuf.c =
(read_minibuf): with the indicated settings of variables,<br></div><div>=
"stack up" all containing minibuffers on the mini-win=
dow of the current<br></div><div> frame. Delete =
another, now superfluous such stacking up.<br></div><div> &nb=
sp; (set_minibuffer_mode): New function.<br></div><div>  =
; (get_minibuffer): Call the above new function (twice), in place of inl=
ine<br></div><div> 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. 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>> 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--
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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).
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
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--
bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.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))
styang@HIDDEN:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#47150; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.