From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67008: 30.0.50; Multiple major mode parents Date: Thu, 09 Nov 2023 00:38:22 -0500 Message-ID: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24920"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ikumi Keita To: 67008@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 09 06:40:35 2023 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 1r0xmN-0006KB-Ho for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Nov 2023 06:40:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0xmE-0007W1-M5; Thu, 09 Nov 2023 00:40:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0xmD-0007Vs-0u for bug-gnu-emacs@gnu.org; Thu, 09 Nov 2023 00:40:25 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r0xmC-0003Pp-OR for bug-gnu-emacs@gnu.org; Thu, 09 Nov 2023 00:40:24 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r0xmn-0001dM-TK; Thu, 09 Nov 2023 00:41:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: ikumi@ikumi.que.jp, bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 05:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 67008 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: Ikumi Keita Original-Received: via spool by submit@debbugs.gnu.org id=B.16995084446241 (code B ref -1); Thu, 09 Nov 2023 05:41:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 9 Nov 2023 05:40:44 +0000 Original-Received: from localhost ([127.0.0.1]:46548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0xmV-0001cb-7f for submit@debbugs.gnu.org; Thu, 09 Nov 2023 00:40:43 -0500 Original-Received: from lists.gnu.org ([2001:470:142::17]:55120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0xmQ-0001cD-Dx for submit@debbugs.gnu.org; Thu, 09 Nov 2023 00:40:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0xlh-0007Tv-Ey for bug-gnu-emacs@gnu.org; Thu, 09 Nov 2023 00:39:53 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0xla-00037n-HF for bug-gnu-emacs@gnu.org; Thu, 09 Nov 2023 00:39:53 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EEBBB100126 for ; Thu, 9 Nov 2023 00:39:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1699508384; bh=K8FvNRU3PLG1dX6T0r7DvbvJICpaX4rdvdn1Mz65fLg=; h=From:To:Subject:Date:From; b=Cfg+OGYqXFLqPZmS/iH7u6izjdyup9jHNRLAqx60DinurQaDVQTKQDdl/dQ0lQZbS ySK5AMG+uDjoSdQTpt68zOG1YK5om/odH/1F+LGmg/F/W9E6ECwAFBH5vhZ/RagZP5 6N5xqLyUXLxrJz500jk6mvgLwgYZw15020eaLdORfnlrdYC1Wa90eNxAPSRyd+0tdY O0NAfeV3C8svvzq7BaN4TYXDTGeca8YrEUAqXKMxs+B0Oia8/UQRaUfuvOo+B5vMp6 D8OgcQJK6L8ONiGc4TAMcqt74YqVpSWDUKLyl9ATh9lqVmpqACb6yJ3EqZ77ufKWDk XBu50zndx7s4g== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 07F05100068 for ; Thu, 9 Nov 2023 00:39:44 -0500 (EST) Original-Received: from pastel (unknown [45.72.227.120]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E54691203D4 for ; Thu, 9 Nov 2023 00:39:43 -0500 (EST) Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274028 Archived-At: Package: Emacs Version: 30.0.50 While it seems difficult to add support for multiple inheritance to `define-derived-mode`, it's fairly easy to allow a major mode to declare itself the spiritual heir of various other major modes beside the one from which it actually inherits. We already have some very basic such cases in our own code: - `locate-mode` inherits from `special-mode` but declares itself as a child of `dired-mode`. - CEDET declares that `c++-mode` is a child of `c-mode`. I'd been toying with this idea for a while because it has seemed useful a few times, tho until now there seemed to be good enough alternatives. But in order to really support AUCTeX modes well, we do need such a thing: we need `LaTeX-mode` to be able to declare itself as a child of `latex-mode` (even tho it does not inherit from it) so that directory-local variables are properly applied to it, which is a fairly common use case. I pushed to the branch `feature/derived-mode-add-parents` a bunch of patches which add support for such limited form of `multiple inheritance`. The patch is fairly large because it goes through all the code that uses the `derived-mode-parent` property and adjusts it to use a few new functions: - `derived-mode-set-parent` and `derived-mode-all-parents` cover basically all previous uses of the `derived-mode-parent` property. - `derived-mode-add-parents` to declare additional parents. The patch also consolidates the code that linearizes the inheritance hierarchy of CL classes, EIEIO classes, and major modes. You can see below the corresponding commit log. There are no doc (or etc/NEWS) changes yet. Any comment/objection? Stefan commit 19445b6b7bb04e44e39ef2e39a620bd3eadb0acd Author: Stefan Monnier Date: Wed Nov 8 11:32:27 2023 -0500 subr.el: Provide a functional API around `derived-mode-parent` The `derived-mode-parent` property should be an implementation detail, so we can change it more easily. To that end, add functions to set and query it. * lisp/subr.el (derived-mode-all-parents): New function. (provided-mode-derived-p): Use it. (derived-mode-set-parent): New function. commit 9c6b22bb3e2126a1ab355b81ae4268ac53c2b6fe Author: Stefan Monnier Date: Wed Nov 8 14:20:09 2023 -0500 (derived-mode-all-parents): Speed up with a cache Most uses of the mode hierarchy don't really need to construct the list, they just need to iterate over it. With single inheritance we could do it just by jumping up from a mode to its parent, but to support the upcoming multiple inheritance we'd need a more complex and costly iterator. Luckily, the inheritance graph is mostly static so we can cache the list of all parents, making `derived-mode-all-parents` cheap enough to be the basis of iteration and keeping the API very simple. * lisp/subr.el (derived-mode-all-parents): Cache the result. (derived-mode--flush): New function. (derived-mode-set-parent): Use it. commit 492920dd5b469e18596a49a62fbefd8ad2cc518b Author: Stefan Monnier Date: Wed Nov 8 22:53:39 2023 -0500 Use new `derived-mode-all/set-parents` functions. Try and avoid using the `derived-mode-parent` property directly and use the new API functions instead. * lisp/emacs-lisp/derived.el (define-derived-mode): Use `derived-mode-set-parent`. * lisp/loadhist.el (unload--set-major-mode): * lisp/info-look.el (info-lookup-select-mode): * lisp/ibuf-ext.el (ibuffer-list-buffer-modes): * lisp/files.el (dir-locals--get-sort-score): * lisp/emacs-lisp/cl-generic.el (cl--generic-derived-specializers): Use `derived-mode-all-parents`. commit 5afa55a946a0271c624359e9de5d62bcaf39729b Author: Stefan Monnier Date: Mon Nov 6 16:57:05 2023 -0500 subr.el: Add multiple inheritance to `derived-mode-p` Add the ability for a major mode to declare "extra parents" in addition to the one from which it inherits. * lisp/subr.el (derived-mode-add-parents): New function. (derived-mode-all-parents): Adjust accordingly. commit 8323394bc801e01dedd95e0ff8d573dd1f5e34ba Author: Stefan Monnier Date: Mon Nov 6 19:05:40 2023 -0500 Use `derived-mode-add-parents` in remaining uses of `derived-mode-parent` Until now multiple inheritance wasn't really used, but some ad-hoc code went a bit beyond the normal uses of the mode hierarchy. Use the new multiple inheritance code to replace that ad-hoc code, thereby eliminating basically all remaining direct uses of the `derived-mode-parent` property. CEDET had its own notion of mode hierrchy using `derived-mode-parent` as well as its own `mode-local-parent` property set via `define-child-mode`. `derived-mode-add-parents` lets us reimplement `define-child-mode` such that CEDET can now use the normal API functions. * lisp/locate.el (locate-mode): Use `derived-mode-add-parents`. * lisp/cedet/mode-local.el (get-mode-local-parent): Declare obsolete. (mode-local-equivalent-mode-p, mode-local-use-bindings-p): Make them obsolete aliases. (mode-local--set-parent): Rewrite to use `derived-mode-add-parents`. Declare as obsolete. (mode-local-map-mode-buffers): Use `derived-mode-p`. (mode-local-symbol, mode-local--activate-bindings) (mode-local--deactivate-bindings, mode-local-describe-bindings-2): Use `derived-mode-all-parents`. * lisp/cedet/srecode/table.el (srecode-get-mode-table): * lisp/cedet/srecode/find.el (srecode-table, srecode-load-tables-for-mode) (srecode-all-template-hash): Use `derived-mode-all-parents`. * lisp/cedet/srecode/map.el (srecode-map-entries-for-mode): * lisp/cedet/semantic/db.el (semanticdb-equivalent-mode): Use `provided-mode-derived-p` now that it obeys `define-child-mode`. commit 0939433b63ab45d18fe1a2db706f66efe7307261 Author: Stefan Monnier Date: Tue Nov 7 18:57:03 2023 -0500 Move EIEIO's C3 linearization code to `subr.el` The code was used to linearize the EIEIO class hierarchy, since it results in saner results than things like BFS or DFS. By moving it to `subr.el` we get to benefit from that same advantage both in `cl--class-allparents` and in `derived-mode-all-parents`. * lisp/subr.el (merge-ordered-lists): New function. (derived-mode-all-parents): Use it to improve parent ordering. * lisp/emacs-lisp/eieio-core.el (eieio--c3-candidate) (eieio--c3-merge-lists): Delete functions, replaced by `merge-ordered-lists`. (eieio--class-precedence-c3): Use `merge-ordered-lists`. * lisp/emacs-lisp/cl-preloaded.el (cl--class-allparents): Use `merge-ordered-lists` to improve parent ordering. * lisp/emacs-lisp/cl-macs.el (cl--struct-all-parents): Delete function. (cl--pcase-mutually-exclusive-p): Use `cl--class-allparents` instead.