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

[João Távora]

Yuan Fu <casouri@gmail.com> writes:

> observe what breaks? Then Joao can either say “I told you” or happily
> found out that this patch works ok.

Those are not the only two outcomes.  It might work OK and not break
anything [*].

However it is not easy to quantify confused users looking to understand
the new meaning of things in dir-locals.el.  Or users wondering why they
need to set Eglot variables in both 'c++-mode-hook' and
'c++-ts-mode-hook' when all they see is 'c++-mode' in
'eglot-server-programs'.

So it might not break, and even have some reasonalby solid theoretical
backend beautifully enshrined in documentation.  But is it the right
thing?  I think not.  Unless I'm mistaken it's already proven to be
confusing even to two seasoned Emacs hackers in this thread (and I'm not
including myself).

And it doesn't do much for two main problems that were presented at the
base: Eglot and Yasnippet.  I.e. Eglot still inescapably needs to report
the language to the server and Yasnippet would be better and much
simpler if it could organize snippets by languages instead of major
modes.

There are better alternatives to this patch:

1. The base modes, which are substantially _already_ in place.  They
   follow the naming convention <lang>-base-mode.  After giving more
   thought to your earlier objection about derived modes overriding
   variables, it doesn't make sense (I can elaborate if you want :-) ).

2. Explicitly associating some major modes with languages or file types.
   This doesn't seem hard and other further uses like suggesting modes
   or packages to a new user based on languages have been proposed.

Nevertheless, I suspect that you want a solution to some real problem
happening today Can you say in your own words what that problem is?  As
I explained, I don't have a good idea of the cases besides Eglot,
Yasnippet and possibly/likely Lsp-mode.

João

[*]: It's possible though.  One way would be for a user to have added
entries to 'eglot-server-programs' for non-TS 'foo-mode' specifically
with 'add-to-list', a very common practice.  Her later 'foo-ts-mode'
entries would be shadowed.  Unlikely, perhaps?  But what about variables
set in '.dir-locals.el' for 'foo-mode' and 'foo-ts-mode'?  Suprising
"magic" aside, it seems these settings will be merged (right?) in
'foo-ts-mode' buffers.  But does this make sense every time?  Even in
our own dir-locals.el there are some settings for 'c-mode' (unrelated to
cc-mode.el) that are not in the 'c-ts-mode' section, but after Stefan's
patch it will be as if they were.  I think it's unavoidable we'll catch
some users off-guard and break things.