[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extending define-derived-mode
From: |
Stefan Monnier |
Subject: |
Re: Extending define-derived-mode |
Date: |
Thu, 01 Jun 2023 00:06:54 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>> 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’t they use major-mode-remap-alist?
Yes, that's one way. With its pros and cons.
> For sure, those that aren’t sharable should go into the not-shared
> hooks. I’m 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’t the easiest to install, people working on multiple machines
> probably want both tree-sitter and no-tree-sitter modes configured and ready
> to go. So I think we’ll see a lot of people having config for both 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’t want multiple-inheritance for activation code.
> 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’s 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 have
> one parent?
The single parent can be a composite map (i.e. using `make-composed-keymap`).
> Here’s 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’t need to pre-define base-modes for every possible
> 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 runs
> the major mode body but doesn’t setup anything that are autogenerated (eg,
> keymap, hooks, etc). This way another major mode is free to reuse other
> mode’s 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
- Re: Extending define-derived-mode,
Stefan Monnier <=
Re: Extending define-derived-mode, Yuan Fu, 2023/06/02