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

[João Távora]

On Fri, Jan 5, 2024 at 6:57 PM Eli Zaretskii <eliz@gnu.org> wrote:

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

electric-pair-mode uses scan-sexps.  Scan-sexps works perfectly to
navigate nested mixed delimiter structures of modes that are not Lisp,
otherwise e-p-m couldn't do it's auto-balancing job.

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

As I am trying to explain, it doesn't have to be a "Lisp sexp".
It just has to be something that scan-sexps can navigate, and
scan-sexps works in all modes.  I'd think that at least
with a good enough grammar it's perfectly possible to do
e.g. show-paren-mode with TreeSitter alone.  And the way this
could work in Emacs is for TreeSitter to feed into scan-sexps.

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

? You write this precisely in the point where I _agree_ with you.
That's the really the opposite of brushing aside.

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

As I am trying to explain, even a one-line empty base mode is useful.

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

Very well, we are violently agreeing.

> This means that the
> base-mode hook will not see a mode that is ready for work, only its
> beginning.

Correct.  But a major-mode doesn't have to be "ready for work" (I presume
you mean ready for editing) for the hook to be useful.  That hook would
be perfectly suitable for setting variables used by minor modes and other
things. (eglot-server-program, flymake-diagnostic-functions,  company-backends,
mode-line-format, etc etc)
For turning on minor modes (eglot-ensure, company-mode, yasnippet-minor-mode,)
For binding commands.

And even without the hook the mere fact that foo-mode and foo-ts-mode
are derived from foo-base-mode according to derived-mode-p makes it
useful.

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

I don't see the problem, really.  Now I see that many mode "base modes" already
exist.  That's great!  That's at least four simplifications to eglot.el's
eglot-server-programs (ruby, python, js and bash/sh).  I'd be happy to
know of more if someone has a fuller list.

And all the base mode definitions could well have settings for the
upcoming eglot-server-program.

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

I couldn't see the problem in either python.el or sh-script.el.  What
do you wish you could do in those base mode bodies on have the user
do in the base mode hooks which is impossible?

João