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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 8 Jan 2024 10:50:57 +0000
> Cc: monnier@iro.umontreal.ca, casouri@gmail.com, 68246@debbugs.gnu.org
> 
> On Mon, Jan 8, 2024 at 3:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > That's not useful, since, for example, TS and non-TS mods for those
> > "no-language" modes will still want to be treated the same in some
> > situations, like .dir-locals.el.
> 
> Yup, so pass them same :language to them and call `get-language-for-mode`
> somewhere in the .dir-locals.el machinery?  Else suggest to use the base mode,
> if it exists.  If it doesn't exist, create it?

There's no "language" here.  Calling things by names they aren't is
not useful.  All it does is create confusion.

> > It attempts to abstract a trait that isn't abstract, by going in the
> > opposite direction of that used for abstractions.
> 
> It's interesting how you state a simple get/set is a "leaky abstraction",
> but then also not an abstraction at all.

It's "leaky" because it "leaks" the idea that it should be a
"language".

> Let's put it like this:  Eglot should probably fix this actual code:
> 
>    (replace-regexp-in-string "\\(?:-ts\\)?-mode$" "" (symbol-name sym))
> 
> to find the language to report to the server.

Eglot should not rely on the assumption that the "language", whatever
it is, is included verbatim in the mode's symbol name.  Neither should
Eglot assume anything else about the name of the mode.

> What if an Eglot users wants some server just for the non-TS mode?  Or a
> Yasnippet user some snippets for such a mode?  Or even just regular
> user some directory-local variable value?

Eglot provides hooks to do that.

> The more I think about this, the more I think this is problematic.
> 
> But if you guys are so confident, sure, let's try it.  If nothing bad
> happens great, else I guess I'll refer users to this thread.

Yes.