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

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 5 Jan 2024 15:16:30 +0000
> Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org
> 
> On Fri, Jan 5, 2024 at 1:26 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > That's right -- but it's justified.  The commonality is usually either
> > very thin or almost non-existent.  If you think about it, you will
> > understand: where the traditional modes use regexps and syntax-ppss,
> > the TS modes use parser-related primitives.
> 
> I _have_ thought about it.  And I started from evidence that
> not everything a major mode dedicated to a language supplies
> is directly related to the parser implementation. Many things
> are, but not all.  So reimplementing a full major mode just
> for changing the praser backend might not make sense.

Experience shows that eventually most if not all of that goes back to
how the mode parses or analyzes the text (a.k.a. "source code").

> > How can you find common
> > grounds between these so different bases for implementation?
> 
> Very easily, I think.  Stefan's patch is one such example.
> What it is fixing?  Tools that want this common ground and haven't
> found it, of course!

What Stefan's patch fixes is the features that depend only on the
mode's symbol, but don't call any mode-specific functions or examine
its data structures.

> Take inserting comments via comment-dwim.

Even comment-dwim already shows a problem: it must determine whether
point is inside a comment, and TS and non-TS modes do that radically
differently.

The commonality could of course be increased by refactoring the
existing stuff so that it uses more abstract interfaces, which could
then be implemented separately for TS and non-TS modes.  But that
requires some motivation, and for now I see no such motivation where
different people maintain the traditional and TS modes.  Such
refactoring is not an easy business, so without the motivation I see
no way for that to happen any time soon.

> Or invoking LSP in any mode for another example.

LSP only cares for the language, so of course it can benefit from
Stefan's patch, because all that matters is the mode's symbol.

> Or consulting documentation.

Again, only the mode's symbol is important.

> Or anything we've built (including muscle memory) that lives on top
> of syntactic abstractions like forward-sexp.

Here you already bump into a problem, because most languages have no
notion of "sexp", so making a TS mode do the same as a traditional
mode is not easy at all.

> Basically any preference that the major-mode expresses regarding an
> orthogonal facility (minor mode or not) should, in principle, be
> shared.

I invite you to compare CC mode with c-ts-mode, and see for yourself
how the common grounds are very small.  It seems surprising at first
sight, but once you look at the code, it is very clear.

> At the very least, it seems a common hook would be useful, and that's
> what an empty foo-base-mode() would give.

Where a base mode makes sense, sure.  But even that causes problems,
since the base mode leaves some stuff not set up, and this various
things that you'd want to do in a mode hook are impossible in the
base-mode hook.