Re: Standardizing tree-sitter fontification features

[Theodor Thornhill]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 5 dec. 2022 kl. 09.58 skrev Theodor Thornhill <theo@thornhill.no>:
>
>> I agree - but in most tree-sitter languages it seems like there usually
>> is no distinction between them.  We need to implement some heuristics to
>> locate a comment above method etc, if I'm not mistaken.
>
> At least distinguish doc comments by their special syntax, such as `--
> !` or `/**`; it's better than nothing and only requires local
> analysis. A grammar tie-in to make sure they aren't misplaced is
> obviously better (and valuable) but it can be a later improvement.

Sure, but I don't think it's too hard.  We could do something like (on
emacs-29 branch):

diff --git a/lisp/progmodes/java-ts-mode.el b/lisp/progmodes/java-ts-mode.el
index 2c42505ac9..abf67a4c14 100644
--- a/lisp/progmodes/java-ts-mode.el
+++ b/lisp/progmodes/java-ts-mode.el
@@ -123,13 +123,24 @@ java-ts-mode--operators
     "|=" "~" ">>" ">>>" "<<" "::" "?" "&=")
   "C operators for tree-sitter font-locking.")
 
+(defun java-ts-mode--font-lock-comment (node override start end &rest _)
+  (when (or (equal (treesit-node-type node) "block_comment")
+            (equal (treesit-node-type node) "line_comment"))
+    (let ((face (if (equal (treesit-node-type (treesit-node-next-sibling node))
+                           "method_declaration")
+                    'font-lock-doc-face
+                  'font-lock-comment-face)))
+      (treesit-fontify-with-override
+       (treesit-node-start node) (treesit-node-end node)
+       face override start end))))
+
 (defvar java-ts-mode--font-lock-settings
   (treesit-font-lock-rules
    :language 'java
    :override t
    :feature 'comment
-   `((line_comment) @font-lock-comment-face
-     (block_comment) @font-lock-comment-face)
+   `((line_comment) @java-ts-mode--font-lock-comment
+     (block_comment) @java-ts-mode--font-lock-comment)
    :language 'java
    :override t
    :feature 'constant


This naive function will work for comments directly above a method.  It
won't try to fix annotations and do other smartness.  The local analysis
is actually a little more complex because you need to extract the
comment text and scan it.  Is a more robust variant of this of interest?

Theo