Re: Need for "-ts-mode" modes

[Philip Kaludercic <philipk@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Thu, 29 Dec 2022 17:08:09 +0000
>> 
>> The issue has been discussed before, but I failed to understand the
>> point of duplicating a lot of modes
>
> 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?

>> or creating new modes that depend
>> on tree-sitter and that don't work or even try to provide some fall-back
>> if the library is not available.
>
> 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.  Sure, if I have the parser installed use
that, but otherwise it would be preferable if instead of giving up with
a warning the keyword list is extracted from
`dockerfile-ts-mode--font-lock-settings' and converted into something
that is useful even if I don't have tree-sitter configured.  And this
doesn't just apply to this mode.

>                   Besides, we've lived this far without major modes
> for those languages, so adding a tree-sitter based one cannot possibly
> do any harm, it can only make things better for Emacs.

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

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


[-- Attachment #2: Type: text/plain, Size: 1978 bytes --]

diff --git a/lisp/progmodes/dockerfile-ts-mode.el b/lisp/progmodes/dockerfile-ts-mode.el
index 40d90cc2df..99fea26c94 100644
--- a/lisp/progmodes/dockerfile-ts-mode.el
+++ b/lisp/progmodes/dockerfile-ts-mode.el
@@ -141,36 +141,24 @@ dockerfile-ts-mode--imenu-1
 ;;;###autoload
 (define-derived-mode dockerfile-ts-mode prog-mode "Dockerfile"
   "Major mode for editing Dockerfiles, powered by tree-sitter."
+  :tree-sitter-settings treesit-font-lock-settings
+  :tree-sitter-features '((comment)
+                          (keyword string)
+                          (image-spec number)
+                          (bracket delimiter error operator))
+  :tree-sitter-indent dockerfile-ts-mode--indent-rules
   :group 'dockerfile
   :syntax-table dockerfile-ts-mode--syntax-table
 
-  (when (treesit-ready-p 'dockerfile)
-    (treesit-parser-create 'dockerfile)
-
-    ;; Comments.
-    (setq-local comment-start "# ")
-    (setq-local comment-end "")
-    (setq-local comment-start-skip (rx "#" (* (syntax whitespace))))
-
-    ;; Imenu.
-    (setq-local imenu-create-index-function
-                #'dockerfile-ts-mode--imenu)
-    (setq-local which-func-functions nil)
-
-    ;; Indent.
-    (setq-local treesit-simple-indent-rules
-                dockerfile-ts-mode--indent-rules)
-
-    ;; Font-lock.
-    (setq-local treesit-font-lock-settings
-                dockerfile-ts-mode--font-lock-settings)
-    (setq-local treesit-font-lock-feature-list
-                '((comment)
-                  (keyword string)
-                  (image-spec number)
-                  (bracket delimiter error operator)))
-
-    (treesit-major-mode-setup)))
+  ;; Comments.
+  (setq-local comment-start "# ")
+  (setq-local comment-end "")
+  (setq-local comment-start-skip (rx "#" (* (syntax whitespace))))
+
+  ;; Imenu
+  (setq-local imenu-create-index-function
+              #'dockerfile-ts-mode--imenu)
+  (setq-local which-func-functions nil))
 
 (provide 'dockerfile-ts-mode)
 

[-- Attachment #3: Type: text/plain, Size: 366 bytes --]


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.

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.