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 18:02:29 +0000
> Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org
> 
> > > Or consulting documentation.
> >
> > Again, only the mode's symbol is important.
> 
> No.  Say some consult-documentation minor-mode relies on
> some setting of 'documentation-function'?

I had info-look in mind.

> > > 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.
> 
> Of course they do!!  How else would electric-pair-mode have worked
> for virtually every language for more than 10 years

forward-sexp moves forward even when there are no parentheses or
braces anywhere in sight.

> Well the reason why e-p-m and these things work today for most ts
> modes is because they are also _using_ the Lisp/C parser based on
> syntax tables and syntax-propertize-function.

That's because a language parser will not have any notion of a sexp,
so it cannot help.

> > 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.
> 
> And this is mainly because CC mode is, well, rather corpulent software,
> let's put it like that.  This is why I wrote it makes sense to start
> from scratch for this one.

A discussion where you brush aside any argument that doesn't fit your
theory is not a useful one.  In Emacs we have to solve problems that
happen in the messy real world, not problems in an ideal world where
everything is according to some elegant theory.

> But would some kind of c++-base-mode hurt in some way? Presuming Alan
> allows it, of course.

Feel free to suggest such a base mode.  If it works and is helpful, we
will install it.  Frankly, I doubt you could come up with a useful
base mode like that: the differences are too large.

> > > 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.
> 
> I don't follow.  Can you give an example of a problem?

Yes, look at python.el and sh-script.el.  The base mode can only go so
far, it must stop before it gets into the stuff that is really
different between the TS and non-TS modes.  This means that the
base-mode hook will not see a mode that is ready for work, only its
beginning.

> In fact I'm happy to see exactly the strategy I suggested is already
> done in ruby-mode.el and ruby-ts-mode.el.  What problems are caused
> by it?

Some modes succeed in that, others don't.  I guess it depends on the
language grammar.

> >  and this various
> > things that you'd want to do in a mode hook are impossible in the
> > base-mode hook.
> 
> I don't follow this part either.  Can you give an example using, say
> the existing ruby-base-mode.

Again, look at the two examples I mentioned above.

> In summary, my position is that regardless of Stefan's patch, which
> I'm not opposed to, we should:
> 
> 1. Use add-derived-mode-parents sparingly and consider foo-base-mode when
> possible.
> 
> 2. have a remove-derived-mode-parent (for the other bug)
> 
> 3. perhaps tighten up what we mean by derived-mode-p in the docs

I have no opinion on that.