From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Date: Mon, 22 Mar 2021 15:12:18 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29460"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 47150@debbugs.gnu.org, acm@muc.de To: Sheng Yang Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 22 16:13:20 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lOMF5-0007Xe-Cl for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 16:13:19 +0100 Original-Received: from localhost ([::1]:36022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOMF4-00009H-Ah for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 11:13:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57426) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOMEo-00007v-M8 for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 11:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46726) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lOMEo-0005Od-9q for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 11:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lOMEo-0002wr-4p for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 11:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Mar 2021 15:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47150 X-GNU-PR-Package: emacs Original-Received: via spool by 47150-submit@debbugs.gnu.org id=B47150.161642594811291 (code B ref 47150); Mon, 22 Mar 2021 15:13:02 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 15:12:28 +0000 Original-Received: from localhost ([127.0.0.1]:58272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOMEF-0002w3-Us for submit@debbugs.gnu.org; Mon, 22 Mar 2021 11:12:28 -0400 Original-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 ) id 1lOMED-0002vo-IE for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 11:12:26 -0400 Original-Received: (qmail 90971 invoked by uid 3782); 22 Mar 2021 15:12:18 -0000 Original-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 Original-Received: (qmail 6515 invoked by uid 1000); 22 Mar 2021 15:12:18 -0000 Content-Disposition: inline In-Reply-To: <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:202837 Archived-At: 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@fastmail.com > E-mail (old but still used): yangsheng6810@gmail.com -- Alan Mackenzie (Nuremberg, Germany).