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

["João Távora" <joaotavora@gmail.com>]

On Mon, Jan 8, 2024 at 1:14 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > > 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".

Oh right, of course.  Who came with this "leaky" idea that there
are programming languages are all?

> > 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.

You could have capped it off with "neither should it work" for
maximum consistency.

Else, it has to have this database itself.  And so does Yasnippet and
likely others.  This is what Stefan had to say about it:

> > I don't think embedding (repeatedly) in YASnippet, CEDET, Eglot, ffap,
> > lsp-mode, (and all the others that I don't happen to know offhand) the
> > knowledge that `FOO-ts-mode` is used for the same files as `FOO-mode`
> > qualifies as "fixing".

So that's why I formalized what others had already proposed, but
you bash it with whatever random CS adjectives you find at hand.

> > 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.

???  I think it's better to not answer when you don't have an answer.