Re: Need for "-ts-mode" modes

[Eli Zaretskii <eliz@gnu.org>]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: emacs-devel@gnu.org
> Date: Thu, 29 Dec 2022 18:26:07 +0000
> 
> > Because this was the simplest way, that created no complications,
> > neither to users nor to the code, and could be added in
> > backward-compatible ways.
> 
> What backwards-compatibility are we taking about here?

Let the users decide whether and when they want to turn this on or
off, and keep their init files and use habits working.

> > I fail to see what's wrong with that.  It is entirely legitimate to
> > have a major mode which depends on an optional feature and doesn't
> > work without it.  
> 
> Naturally, if there is no way around this.  My argument is that there
> is.  What prompted me to ask this question was when I just opened a
> Dockerfile and a warning popped up, telling me that I was missing the
> right libraries.  I took a peak inside of dockerfile-ts-mode, and found
> the following
> 
> --8<---------------cut here---------------start------------->8---
> (defvar dockerfile-ts-mode--keywords
>   '("ADD" "ARG" "AS" "CMD" "COPY" "CROSS_BUILD" "ENTRYPOINT" "ENV"
>     "EXPOSE" "FROM" "HEALTHCHECK" "LABEL" "MAINTAINER" "ONBUILD" "RUN"
>     "SHELL" "STOPSIGNAL" "USER" "VOLUME" "WORKDIR")
>   "Dockerfile keywords for tree-sitter font-locking.")
> --8<---------------cut here---------------end--------------->8---
> 
> For me, using these keywords would provide all the "functionality" I
> could need from a Dockerfile.

If you want to provide a dockerfile mode without tree-sitter, please
do.  I'm saying that having just a TS-supported mode is better than
not having any mode.

> With the exception that a warning is generated, popping up a new window,
> which is distracting.

Not a disaster, IMO.

> >> Or the re-phrase the question, why can't tree-sitter support be
> >> implemented by extending `define-derived-mode', ideally in such a way
> >> that can be translated to some kind of font-lock rules for basic syntax
> >> if the library is not installed.
> >
> > Because it doesn't work.  Tree-sitter supported modes are not derived
> > modes, they are completely different modes with different settings
> > which make no sense when tree-sitter is not used.
> 
> I am not talking about deriving foo-ts-mode from foo-mode, but adding a
> keyword to `define-derived-mode' that would generate code to try to make
> use of tree-sitter if available, and fall back to traditional font
> locking if not.

The *-ts mode provide more than just fontifications.  They provide
indentation, navigation, and Imenu support.  And they do that in ways
that are radically different from the "traditional" ways we did this
stuff, with data structures and algorithms that are very different.
If you think you know how to extend define-derived-mode so that we
could treat tree-sitter as some enable-FOO style variable, please show
the code, and let's see whether it's clean enough for our palate.  But
please do this for a serious major mode, like Python or C/C++, not for
dockerfiles, because that's where we bumped into problems that
eventually led to what we have now.  We did try to do something like
that before.

> Perhaps it would be even better to bundle all the tree-sitter related
> options into a single object, define it as a defvar and pass that via a
> keyword.

Feel free to propose how to do that.  We tried several different ideas
and each one of them either had problems or was not cleaner than what
we have.

> What I want to know is, if this is viable (as I plan to find out in the
> next few days), would it be possible to change the current route before
> 29.1 is released, so as to avoid committing to the current strategy.

You can try.  I would like to start a full feature freeze in a day or
two, so I'm not sure you will have enough time.  And it isn't like we
didn't try various approaches during the past two months, so frankly I
don't think that a better way even exists.  But if you come up with
some very bright idea, who knows?