Re: Extending define-derived-mode

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

> 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’s 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’s something I personally want:
>>    it would be nice if every major mode can
>>    have a hook that’s not run by its derived modes. Use case:
>>    sage-mode inherits python-mode. I have eglot-ensure in
>>    python-mode-hook but don’t want it when using sage-mode. Right now
>>    I have to wrap eglot-ensure with a lambda function so that it only
>>    runs when major-mode = 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