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: Thu, 01 Jun 2023 00:06:54 -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="4897"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org, mickey@masteringemacs.org, theo@thornhill.no, dgutov@yandex.ru To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 01 06:08:05 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 1q4ZbY-00013S-3u for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Jun 2023 06:08:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4Zae-0006Rv-4z; Thu, 01 Jun 2023 00:07:08 -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 1q4ZaY-0006Ra-K2 for emacs-devel@gnu.org; Thu, 01 Jun 2023 00:07:02 -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 1q4ZaW-0004RN-N0; Thu, 01 Jun 2023 00:07:02 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 120871000C3; Thu, 1 Jun 2023 00:06:59 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D93F610002A; Thu, 1 Jun 2023 00:06:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1685592417; bh=UJEQdnXMbkBJnx9FGwvlR9M5HxyshOBx6NOaTp7STbw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lzi8VLWS3+FLyOp3p3DEODZS4UEy6Upck6x9ndQCnmkvQOkRGsRVcgfnZKfyC3yBA 0CF0iyMf0JSsBeJT1S0ebDsKUuJa0+gD0R+DgB3t/ev0laCs0CI7cXQgIzxNmvQf3A NVzA0Cio1sHif61BKjDJlG3nO/znmQ46xfDlF33ko9XQAHUjsKF5wMbnHG3CUviFeI EoHBxBt1T+3hd2FgidqsCUXn2d0rMaTQTIzyGp9ALM0Cp6CAXYsNgAPylnqYEbeglh 4Up4zWkmlJMzDca0wpKj+BS61LG8voN+518fq2RLUfME/f+xVYHpZXXzjiA14/PFg/ zXE1blS74/OSg== Original-Received: from pastel (unknown [167.88.20.246]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 70FD812047F; Thu, 1 Jun 2023 00:06:57 -0400 (EDT) In-Reply-To: (Yuan Fu's message of "Wed, 31 May 2023 14:31:06 -0700") 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:306473 Archived-At: >> 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. > Couldn=E2=80=99t they use major-mode-remap-alist? Yes, that's one way. With its pros and cons. > For sure, those that aren=E2=80=99t sharable should go into the not-shared > hooks. I=E2=80=99m mainly saying that there should be a shared hook, so = users > _can_ share some of the configs. Ideally, I agree, tho it's not terribly hard for the user to share code between hooks, so it's not absolutely indispensable. >> 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). > > Keep in mind that when people try out tree-sitter modes, they are unlikely > to just throw away their config for the old mode; also since tree-sitter = and > grammars aren=E2=80=99t the easiest to install, people working on multipl= e machines > probably want both tree-sitter and no-tree-sitter modes configured and re= ady > to go. So I think we=E2=80=99ll see a lot of people having config for bot= h modes (me > included). Good point. > And in general, any configuration that takes a major-mode symbol as > the key. There are quite a few of them in Emacs. I think this is > a big motivation for having multiple inheritance for derived-mode-p, > and sharing a base mode. I think the case for support of multiple inheritance in `derived-mode-p` is fairly compelling, indeed. > I agree that we don=E2=80=99t want multiple-inheritance for activation co= de. > Also, as Juri pointed out, we can encapsulate code into functions and > call functions in major mode body. Multiple-inheritance for hooks and > maps has the potential disadvantage of being confusing. Right now > it=E2=80=99s clear what hooks are run when a major mode turns on, but with > multiple-inheritance it may not be. Normally, `define-derived-mode makes sure that the docstring states it. > How do you setup multiple keymap parents? I thought a keymap can only hav= e one parent? The single parent can be a composite map (i.e. using `make-composed-keymap`= ). > Here=E2=80=99s another wild idea: we keep single-inheritance for > define-derived-mode; major modes for the same language inherits from > the same base mode; add a feature where xxx-base-mode is automatically > defined when someone defines a major mode with xxx-base-mode as > parent, so we don=E2=80=99t need to pre-define base-modes for every possi= ble > language; Sounds hackish. E.g. what would the `xxx-mode` docstring say about which hooks are run? > Maybe defien-derived-mode can additionally define a function that only ru= ns > the major mode body but doesn=E2=80=99t setup anything that are autogener= ated (eg, > keymap, hooks, etc). This way another major mode is free to reuse other > mode=E2=80=99s setup while not inheriting from that mode. Maybe we could offer a way to call "the mode's setup code", tho it's not completely clear what that would do. E.g. would that run `:after-hook`? Oh wait, so maybe we should expose a major mode as a kind of "struct" with accessors to get its keymap, hook, setup-code-function, :after-hook function, ... maybe that could be useful. Stefan