Re: Extending define-derived-mode

[Yuan Fu <casouri@gmail.com>]

> On May 31, 2023, at 9:06 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>> 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.

What do you consider it’s cons? To me it’s more-or-less just a nicer auto-mode-alist without needing to fiddle with regular expression.

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

Right, a nice-to-have.

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

Makes sense, normally there won’t be more than 3 levels of inheritance anyway so it should be fine.

> 
>> 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`).

But IIUC that creates a new map instead of pointing to the parent maps, so any change in the parent map are not reflected in the child map, which is kind of the point of inheriting maps.

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

xxx-base-mode-hook, and…uh, right, we need to specify which mode xxx-base-mode inherits, hmm.

Yuan