Re: Extending define-derived-mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 2 Jun 2023 00:50:07 -0700
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel@gnu.org,
>  mickey@masteringemacs.org,
>  theo@thornhill.no,
>  dgutov@yandex.ru
> 
> > It's a good point, indeed, but with some mode pairs is very hard
> > (read: impossible) to achieve.  A notable example is c-mode and
> > c-ts-mode: the former has a lot of mode-specific commands and features
> > that cannot be used with the latter, because there's no equivalent
> > infrastructure that supports the same interfaces, and sometimes
> > because the feature makes no sense in a TS-based mode.  We try very
> > hard to use the same key bindings and variable names where it does
> > make sense, but the group of features where that is possible is very
> > small.  For example, all the enormous set of features we have in CC
> > mode around indentation and its customization cannot be "ported" to
> > c-ts-mode and c++-ts-mode, because the latter is built on completely
> > different analysis of the text.  Another example is the ad-hoc support
> > for some frequently-use macro names that CC mode has.
> 
> I fully agree. Note thought that I wasn’t saying ts and non-ts modes should accept the same set of configs. I know all-too-well that’s impossible (for the majority of modes). I was saying that sometimes there are configs that can be shared (enabling electric-quote-local-mode, for example), and it would be nice to put them in a single hook rather than duplicating the code in two hooks. 

For users to be able to share stuff like electric-quote-local-mode
we'd need to rewrite those supporting modes to allow that.  When one
of the two modes uses regexps and syntax tables, whereas the other
uses treesit-based parsers, this is not a trivial task.  I invite you
to audit the various electric modes we have and see how many of them
can be shared with minimum effort between non-TS and TS modes.