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.devel Subject: Re: Extending define-derived-mode Date: Tue, 30 May 2023 10:16:57 -0400 Message-ID: References: <20F07C52-6B39-4B24-8433-82E2226EADA6@gmail.com> <83zg5mf62s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6596"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Yuan Fu , emacs-devel@gnu.org, mickey@masteringemacs.org, theo@thornhill.no, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 30 16:18:06 2023 Return-path: Envelope-to: ged-emacs-devel@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 1q40An-0001U6-Q2 for ged-emacs-devel@m.gmane-mx.org; Tue, 30 May 2023 16:18:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q40AA-0000yJ-Nj; Tue, 30 May 2023 10:17:26 -0400 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 1q409t-0000sC-O5 for emacs-devel@gnu.org; Tue, 30 May 2023 10:17:12 -0400 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 1q409r-0008ER-2t; Tue, 30 May 2023 10:17:08 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 801B21000BC; Tue, 30 May 2023 10:17:03 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 27F19100006; Tue, 30 May 2023 10:17:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1685456222; bh=qGpwF7vubp4+GWVtUXRFJbi7/KsqRYyx/Xg3w2yjQBc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=V/5OcBOKUcnJQOohlLuRdFDA0ahbTo8YS4Sohy7gToabI+NHxT0eVI6sO5Nxk4ln0 hBvOAVD9Ft2YtfX9KwIDyvSgzUOHx9wtYyCd5fKG0FlqJ5i5T1OCumRFxvkI091+qT IA+QHY3z1PxF54efgKVsZ0QrB8c371LwRv7wHnCUqqaeLnPZFSSYNoqu9wOEv73tFQ iSHPOgvYfZ1z0t+6nWKyrBcw+sXiDa+gkLwz+ew7v9L+avHrK4DMC1t4rHElrvciH1 LfOxFPCfJkgAJIUZFH7Z7JthkCACefR0/LEoInt8eOe0SKYK8UiSM8rL5LSSr9Z9Is VSgY063eqkHvQ== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0A0871204B3; Tue, 30 May 2023 10:17:02 -0400 (EDT) In-Reply-To: <83zg5mf62s.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 May 2023 13:48:27 +0300") 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306411 Archived-At: > You are basically talking about different modes that support the same > programming language or file format. We never had this in Emacs, with > (AFAIK) the single exception of perl-mode vs cperl-mode, which never > played well. Not quite: within Emacs there's at least pascal.el vs opascal.el and sgml-mode vs nxml-mode, and depending on how you define it there's also postscript-mode vs doc-view-mode, as well as c-mode vs image-mode (for XPM files). And if we consider packages not bundled with Emacs, there are many more case:s such as latex-mode vs LaTeX-mode, python.el vs python-mode.el, js.el vs js2.el vs js3.el, octave-mode vs matlab-mode. > I think some thought was invested in trying to reconcile > them (Stefan, am I right?), but we never came up with a good solution. > Not sure if that is a general problem or not. We don't really have a good answer yet, no. `major-mode-remap-alist` is aimed at this problem, but brand new so it's not clear how useful it will be for that and it's definitely not a complete solution. >> 1. Fallback modes: user enables xxx-ts-mode, but there=E2=80=99s no >> tree-sitter grammar for xxx, so Emacs falls back to xxx-mode >> instead. This feature is also desirable for some non-tree-sitter >> modes, like TeX modes. Ideally the dispatch should happen before >> major mode does anything. > > This fallback must be user-controlled. I don't see this as a big problem, actually (there are already several mechanisms that can do that). The question of how "user enables xxx-ts-mode" is probably harder. >> 2.1 For xxx-mode and xxx-ts-mode, there should be shared hook. More >> generally, we want to be able to have a shared hook for similar >> modes (same language, similar language, etc). As Eli explains, this is not always desirable. And at other times it *is* desirable: the users's hook function can set/use features that are specific to one of the alternative, but they can also set/use features that are shared between the alternatives :-( Most users use only one of the alternatives, tho, so it's usually not a big problem (other than introducing incompatibilities when Emacs's defaults change from one alternative to another). It can be more annoying for `.dir-locals.el` per-mode settings. >> More generally, if there is a language X and a derived language Y, >> and we have x-mode, x-ts-mode, y-mode, y-ts-mode, how should >> inheritance of code and hooks works among them? y-mode probably >> wants to inherit from x-mode, and y-ts-mode probably wants to >> inherit hook (but not necessarily code [1]) from x-ts-mode. `y-ts-mode` can explicitly run `y-mode-hook` (or `x-ts-mode-hook`). We may more generally want to extend our notion of "derived" mode to allow "multiple inheritance". For the actual activation code part, multiple inheritance is a hard problem that we probably don't want to tackle, but we can easily run several parent hooks, setup multiple keymap karents, and make `derived-mode-p` support multiple parents. >> 3. Unrelated to tree-sitter, here=E2=80=99s something I personally want: >> it would be nice if every major mode can >> have a hook that=E2=80=99s not run by its derived modes. Use case: >> sage-mode inherits python-mode. I have eglot-ensure in >> python-mode-hook but don=E2=80=99t want it when using sage-mode. Righ= t now >> I have to wrap eglot-ensure with a lambda function so that it only >> runs when major-mode =3D python-mode. > > What is wrong with that solution? Except for the maybe minor > inconvenience of having to use a lambda-function, what different way > of doing this would you envision except telling define-derived-mode to > run some hook only under this-and-that condition? While I tend to agree that it's not a big deal, I also agree that it's arguably cleaner if parent modes are kept "abstract", so rather than have `c++-mode` inherit from `c-mode`, you make them both inherit from a `c-base-mode`. It tends to smell of overkill, tho. Stefan