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

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

On Sat, Jan 6, 2024 at 8:07 AM Eli Zaretskii <eliz@gnu.org> wrote:

> let's agree to disagree, because I already explained this twice at
> least.

I was just commenting on your earlier words

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

That's manifestly wrong.  Even with a limited understanding of what
a sexp is, it can definitely contribute to sexp navigation as used
by scan-sexp clients.

> Again, if you disagree, let's agree to disagree.

Yes, let's.  But what you said doesn't contradict my assertion that TS
the can feed into scan-sexps in ways that are useful.

> > And the way this could work in Emacs is for TreeSitter to feed into
> > scan-sexps.
>
> I'm not sure I understand how TS could feed scan-sexps.  Did you look
> at the implementation of scan-sexps?  AFAICT, there's no way to base
> the code there on TS, except by providing a completely different
> implementation (assuming TS parsers even provide the required
> information).

One reasonably effective way to do it is just have
syntax-propertize-function propertize text based on TS nodes, which
is what c-ts-mode does today to make show-paren-mode do the right
thing to angle brackets.  Pretty useful already.  You're still running
through text properties and that's maybe not very pretty, but an
implementation detail all the same.  There could be be some more
efficient connection between sexps and TS (or whatever parser)
later on.

> > > > > 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.
>
> You "agree" for the wrong reasons.  You are, in fact, claiming that
> the CC mode cannot be an example of a problem because of unrelated
> reasons.  I'm saying that the reasons are related.

Actually it _could_ be an example.  A c-uber-base-mode would have
_some_ benefit, like it would be a good place to stash snippets.
Just not as much benefit as others which have code.

> > > 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.
>
> Stefan's patch solves these cases in a simpler manner.

I don't oppose Stefan's patch strongly, but I don't think it's
simpler.  For one, it's innovative, a new way to do things
that we could already do with a simpler-to-reason inheritance
that we've had much longer.

As far as motivation goes, the problems in Eglot and Yasnippet
are easily solvable without it.  Not sure about CEDET.

As Stefan K points out this needs calling out in *Help*.

> > I couldn't see the problem in either python.el or sh-script.el.
>
> Search for bugs in those two files, and you will see the issues that I
> had in mind.

Yes, will most definitely start my "search for bugs" in two
files totalling 10000 lines and you know in 200 years or so.

João