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

[Stefan Monnier]

[ IMO, it would indeed be a good idea to try and write some abstraction
  layer so we can share more code between modes parsing with
  syntax-tables/tree-sitter/wisi/SMIE/younameit.  It will also be very
  useful when tree-sitter goes the way of the dodo.

  But that's a difficult job, and with limited immediately-visible
  benefits to the end users.  In the mean time, we're stuck with major
  modes that don't share much code.  ]

Whether it's worthwhile to have a `FOO-base-mode` or not depends on
the specifics, but it's largely an implementation detail.  More
importantly it's not directly relevant to this here bug, because
I want to say "FOO-ts-mode is a kind of mode for FOO, so it's
a kind of FOO-mode".  There are very few YASnippets for FOO-base-mode,
instead they're all for FOO-mode.  Similarly, Eglot doesn't have rules
for FOO-base-mode, only for FOO-mode.

That's why in my patch I add `python-mode` as an extra parent of
`python-ts-mode` even though they both share `python-base-mode` as
their parent.

IOW, in my patch, I'm using `FOO-mode` not really as the name of a major
mode, but rather as the name of a *file type*.
I already mentioned this distinction in the bug-report where
I introduced `major-mode-remap-alist`: Emacs usually conflates
file-type and major-mode, which works great where there's only one major
mode for a given file type, but less great where there are
several alternatives.


        Stefan


João Távora [2024-01-05 23:20:26] wrote:

> 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