emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tree-sitter and major mode inheritance


From: Yuan Fu
Subject: Re: Tree-sitter and major mode inheritance
Date: Sat, 19 Nov 2022 09:17:11 -0800


> On Nov 19, 2022, at 7:19 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>> Anyway, does anyone think this is a good/bad idea? Should I go implement
>>> this on css, js, c, etc? It can also be the other way around: instead of
>>> having c-mode being the virtual mode, we can leave c-mode as-is, and have
>>> a c-base-mode inherited by c-mode and c-ts-mode. And similarly
>>> rss-base-mode, rss-mode, and rss-ts-mode.
>> 
>> I'd prefer leaving the original modes as-is.  That should cause less
>> compatibility problems, I think.
>> 
>> Stefan, any thoughts?
> 
> To the extent that Emacs-29's new `major-mode-remap-alist` can be used
> to select which mode to use, we can indeed leave the original modes
> as-is.
> 
> Another argument in favor is that it's a bit tricky to make `<foo>-mode`
> both the parent mode and the standard entry point: we do that for
> `tex-mode` but the implementation is ugly.
> [ If it weren't for this implementation problem, it would be my
>  favorite choice.  So maybe the better option is to add specific support
>  for that in `define-derived-mode`, where we could implement it
>  cleanly and thus also fix the ugly gymnastics of `tex-mode`.  ]
> 
> OTOH it's a bit jarring to have the generic term `<foo>-mode` refer to
> a specific implementation.
> 
> For that reason, my preference is for:
> 
> - `<foo>-<abstract/parent/base/common>-mode` as the shared parent.
> - `<foo>-mode` as a dispatch function that calls the appropriate specific
>  major mode which could be `<foo>-ts-mode`, or `cc-<foo>-mode`, or
>  `<foo>-with-JSX-mode`, or …

If we are already renaming existing modes (cc-<foo>-mode), why don’t we use the 
generic name <foo>-mode for the virtual parent mode? It would be nicer if the 
generic mode (<foo>-mode) is an actual mode, with mode hooks, keycaps, etc, 
rather than simply a dispatch function.

Plus, if we make <foo>-mode a command rather, all existing configuration of 
<foo>-mode breaks: there is no such major mode anymore, users need to use 
either <foo>-base-mode or one of <foo>-cc/ts-mode.

Yuan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]