Re: Extending define-derived-mode

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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