bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes

[João Távora]

On Sat, Jan 6, 2024 at 3:19 AM Yuan Fu <casouri@gmail.com> wrote:
>
> I certainly welcome base-mode, I’m the one that added them in the first 
> place. But I also want to point out that they are only a partial solution. 
> For one, adding the base mode needs cooperation from all the major mode 
> authors. For built-in modes, that’s not a (big) problem; for countless 
> third-party modes out there, I don’t have high hopes for it.

I don't think this is such a serious problem.  Ultimately, the
affected party aren't major modes themselves, it's the minor
modes that base decisions on 'major-mode' variables and
derived-mode-p.  So far examples are Eglot and Yasnippet (some
unknown way in CEDET).  Expressing the "foo-ts-mode" to
"foo-mode" relation directly in these minor modes isn't really
hard, in fact Eglot already does it for something completely
different that Stefan's patch wouldn't be able to fix anyway:

  (or language-id
      (or (get sym 'eglot-language-id)
          (replace-regexp-in-string
              "\\(?:-ts\\)?-mode$" ""
              (symbol-name sym))))

This is hacky but it works fine.  To do better, we would need
an abstraction like

   (get-mode-family major-mode)

So, personally I think Stefan's patch a rather heavy hammer
to fix something that has many alternatives.

> The good thing about derived-mode-add-parents is that it doesn’t need major
> mode author’s cooperation. Even a normal user can do it themselves.

Yes, precisely that's good.  I actually think
derived-mode-remove-parents is more useful, as it would fix a
real bug (bug#67463) that doesn't seem to have _any_ other solution.

> Then there is the problem Eli pointed out, base-mode hooks runs before child 
> major mode body does. It’s probably fine for most of the things, but if you 
> want to change some buffer local variable that the major mode sets, base-mode 
> hook can’t help. (Arguable a niche use-case, but my point is base-mode hooks 
> have their limits.)

As Dmitry pointed out, this is so for normal inheritance.  It's
not really a problem of the mechanism itself.

> As for adding xxx-mode to xxx-ts-mode’s parent, I think it’s fine? Like 
> others in the thread, I couldn’t think of a scenarios where this will be 
> problematic. I thought about adding xxx-lang as the parent of both xxx-mode 
> and xxx-ts-mode, but that’s probably not very helpful, since the goal is to 
> make things work for ts-mode without needing to change the existing code, and 
> using xxx-lang still requires modifying existing code.

Dunno if problematic, time will tell.  I have run into
"endless cycle" problems with bad derived-mode-p in the past.
Granted, these were all bugs in my code, since fixed.
Above all I think it's a bit akward for users to grasp
this whereas a cleaner "file type registry/language family"
or some other cleaner concept seems more solid.

But maybe if I squint very hard and try to think of
a (single?) "extra parent" as the "language family", maybe
it will work flawlessly.

Regardless I still think the concept of "language id", "file type"
or "family" or whatever should be described somewhere and
linked to our particular implementation of it, currently
based on "extra parenting".