From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Date: Sun, 18 Apr 2021 11:22:18 -0400 Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11328"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 18 17:23:22 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 1lY9Gb-0002oF-Cp for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 17:23:21 +0200 Original-Received: from localhost ([::1]:38978 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lY9Ga-0006LT-G4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 11:23:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34068) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lY9GI-00067d-C3 for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 11:23:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35895) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lY9GI-0003U1-5B for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 11:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lY9GI-0003SC-1h for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 11:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Apr 2021 15:23:01 +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.161875934813224 (code B ref 47150); Sun, 18 Apr 2021 15:23:01 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 18 Apr 2021 15:22:28 +0000 Original-Received: from localhost ([127.0.0.1]:47440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY9Fk-0003RD-EL for submit@debbugs.gnu.org; Sun, 18 Apr 2021 11:22:28 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY9Fi-0003Qo-OL for 47150@debbugs.gnu.org; Sun, 18 Apr 2021 11:22:27 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4541210022F; Sun, 18 Apr 2021 11:22:21 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9EE7F10021B; Sun, 18 Apr 2021 11:22:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618759339; bh=hFVOC11IPSz0KYesdMqkpDYODOL+Raen3ALPU9gIyDw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=jSshPMg99743FWDIgAXAPlCC71OPzhjEFMUIVwgYpDMwC7hBhJJf1PoWRZv5JXjfr +HtgrzsQM5JZlxSs1UcBY5OY/SxHme1ymc91veepVPx9zFNrb55v/ldov3zorpeoIq UGicMixDbSeD72F9eA6v6ERpOrh1nl0donVKy5MaoQd4dxwVEbU8WPwssIHIb22qrM i9wbVG/oVNiPYssHGJH7Oom+8asuKl5t1pbEI7Ry6w3Pkxbl9ciXevo48FsfUqeVuP frKQpq81DnYAbK80HTleOwU677s4+c4Rf2fLp9ADcuuX7AzyuxNV/imOXK1zjy7jV4 scYI4dnZZVY7Q== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5EFDD1201FF; Sun, 18 Apr 2021 11:22:19 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sun, 18 Apr 2021 11:14:20 +0000") 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:204347 Archived-At: >> 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). No, you could also use (derived-mode-p ) instead of (minibufferp). >> > 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. :-( Could you explain the problem you see with calling it one extra time? > 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. These "extras" haven't caused any trouble in all the other major modes where they're not used (including minibuffer-inactive-mode), so it seems to me like you're worried about something perfectly harmless. > 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. :-( I disagree. The minibuffers are normal buffers, and the more normal we can make them, the better. Clearly, the major modes that make sense in a minibuffer will almost invariably be different from the major modes that make sense in other buffers, but that doesn't mean that the concept of "major mode" is wrong for minibuffers. Not at all. On the contrary, from where I stand, it is The Right Thing. I'd argue that we're de-facto already using major modes, just without the advantages that come from having conventions. E.g. `minibuffer-setup-hook` is the hook for the "parent major mode" of all the minibuffer "major modes". The `minibuffer-*-map` are the keymaps of the various different "major modes". The advantages we can gain by bringing the conventions of "real" major modes would be for example that `C-h m` would give useful information when used in the minibuffer. > 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. Sounds good to me ;-) Stefan