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

From: João Távora <[email-masked]>
Date: Sat, 6 Jan 2024 14:54:49 +0000

On Sat, Jan 6, 2024 at 3:19 AM Yuan Fu <[email-masked]> 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".