Re: Update on tree-sitter structure navigation

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: casouri@gmail.com, emacs-devel@gnu.org, danny@dfreeman.email,
>  theo@thornhill.no, jostein@secure.kjonigsen.net, dev@rjt.dev,
>  wkirschbaum@gmail.com, pedz@easesoftware.com, dgutov@yandex.ru
> Date: Fri, 08 Sep 2023 12:03:58 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01251.html
> >   https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01293.html
> 
> Thanks!
> 
> According to the discussion, the main problem is that interleaving
> ts-related and ts-unrelated code in the same mode is risky. It is safer
> to have a dedicated foo-ts-mode rather than modifying the existing
> foo-mode.

No, that's the wrong conclusion.  The main reason is that mixing these
modes makes no sense in most cases, due to completely different
infrastructures they use.  The main aspects of a major mode --
font-lock, indentation, and defun- and expression-level navigation --
are based on such different grounds that you cannot possibly reuse
them.  And once those are implemented on a different basis, what is
left to share?

> However, separate *-ts- and *- modes create a problem when user config
> tailored for old, non-ts mode will no longer work.

There's no argument that this is a disadvantage that causes problems
to users.  The challenge is to find a good solution.  The basic
requirements from such a solution are:

  . as much as possible, provide the same or equivalent features
  . allow easy migration of customizations from an old mode to a TS mode
  . allow to switch easily between the two kinds of modes for the same
    PL, in both directions (for example, to let users try the TS mode
    and switch back if they don't like it)
  . avoid complicating the maintenance too much

> For example, c-ts-mode has `c-ts-mode-indent-offset', while cc-mode
> has c-basic-offset in `c-style-alist'.

Yes, but CC Mode's indentation customizations cannot be ported to
c-ts-mode because they are based on a completely different
classification of syntactic elements, so what do you propose as the
solution for this particular schism?

As for c-style-alist, the elements of the style are also completely
different.  So for now, we provide a different variable for c-ts-mode
which supports the subset of built-in styles supported by CC Mode.  If
you have a concrete proposal for a better solution, let's hear it.

> Ideally, user-facing API should be shared between the modes: defcustoms,
> faces, and certain high-level functions like `c-set-style'.

Again, there's no argument about the ideal, and never was.  We just
couldn't find a way of implementing this ideal without bumping into
serious problems.  May I suggest to study the code of at least a few
pairs of modes, and see what I'm talking about?

> One might slowly:
> 1. Add support of foo-mode's defcustoms to foo-ts-mode, when applicable
> 2. Create a shared API between foo-mode and foo-ts-mode that will call
>    the appropriate implementation depending on which mode is active.

This sounds great in the abstract, but in practice bumps into serious
implementation problems.  The names of the variables are the least of
our problems; the fact that we provide different names in the TS modes
is to make sure no one expects the non-TS customizations to work with
TS modes, because that's currently impossible: the internal structure
of the data of the variables, as well as the way the related internal
functions work, is too different.  As an exercise, try to create an
API for font-lock that could be shared by a TS and a non-TS mode.  If
you succeed, and if the result is significantly different from what we
already have, please present the solution, because maybe we have
missed something.