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: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Date: Mon, 22 Mar 2021 16:27:30 +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=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31103"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, acm@muc.de To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 22 17:28:13 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 1lONPY-0007xv-Sg for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 17:28:12 +0100 Original-Received: from localhost ([::1]:52798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lONPX-0008Ok-Sl for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Mar 2021 12:28:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53828) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lONPO-0008Ld-Lw for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 12:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46797) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lONPO-0006HK-Dv for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 12:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lONPO-0004qc-87 for bug-gnu-emacs@gnu.org; Mon, 22 Mar 2021 12:28: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 16:28: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.161643045918605 (code B ref 47150); Mon, 22 Mar 2021 16:28:02 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 16:27:39 +0000 Original-Received: from localhost ([127.0.0.1]:58343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lONP1-0004q1-Fc for submit@debbugs.gnu.org; Mon, 22 Mar 2021 12:27:39 -0400 Original-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 ) id 1lONOz-0004pn-LB for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 12:27:38 -0400 Original-Received: (qmail 42567 invoked by uid 3782); 22 Mar 2021 16:27:31 -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 17:27:30 +0100 Original-Received: (qmail 7830 invoked by uid 1000); 22 Mar 2021 16:27:30 -0000 Content-Disposition: inline In-Reply-To: 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:202840 Archived-At: 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).