bug#60256: 29.0.60; Maybe improve tree sitter default treesit-language-at function

bug#60256: 29.0.60; Maybe improve tree sitter default treesit-language-at function

[Wilhelm H Kirschbaum]

We can detect the language from treesit-parser-included-ranges, so
instead of taking the first parser from the list what about taking 
the
first parser within known ranges?

diff --git a/lisp/treesit.el b/lisp/treesit.el
index 6407669118..f08bb1cd40 100644
--- a/lisp/treesit.el
+++ b/lisp/treesit.el
@@ -136,8 +136,20 @@ treesit-language-at
 parser in `treesit-parser-list', or nil if there is no parser."
   (if treesit-language-at-point-function
       (funcall treesit-language-at-point-function position)
-    (when-let ((parser (car (treesit-parser-list))))
-      (treesit-parser-language parser))))
+    (let ((language-in-range
+         (cl-loop
+          for parser in (treesit-parser-list)
+          do (setq range
+                   (cl-loop
+                    for range in (treesit-parser-included-ranges 
parser)
+                    if (and (>= point (car range)) (<= point (cdr 
range)))
+                    return parser))
+          if range
+          return (treesit-parser-language parser))))
+    (if (null language-in-range)
+        (when-let ((parser (car (treesit-parser-list))))
+          (treesit-parser-language parser))
+      language-in-range))))


Maybe there is a better way of doing this, but seems like it can 
be
generic enough to make this work without having to set
treesit-language-at-point-function for the majority of the cases.

Wilhelm

bug#60256: 29.0.60; Maybe improve tree sitter default treesit-language-at function

[Eli Zaretskii]

> From: Wilhelm H Kirschbaum <wilhelm@floatpays.co.za>
> Date: Thu, 22 Dec 2022 12:30:09 +0200
> 
> 
> We can detect the language from treesit-parser-included-ranges, so
> instead of taking the first parser from the list what about taking 
> the first parser within known ranges?

Yuan, any comments?

bug#60256: 29.0.60; Maybe improve tree sitter default treesit-language-at function

[Yuan Fu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Wilhelm H Kirschbaum <wilhelm@floatpays.co.za>
>> Date: Thu, 22 Dec 2022 12:30:09 +0200
>> 
>> 
>> We can detect the language from treesit-parser-included-ranges, so
>> instead of taking the first parser from the list what about taking 
>> the first parser within known ranges?
>
> Yuan, any comments?

Yeah, sorry for the delay. I don’t think it’s worth it, because (1) I
expect major modes with multiple langauges to implement
treesit-language-at-point-function which takes care of all the work, and
(2) in the rare case where there are multiple languages and no
treesit-language-at-point-function, using the first language whose range
spans point (this patch) is not necessarily correct: the host language (eg, HTML
among HTML, CSS & JavaScript) always covers the whole buffer, only
embedded languages has ranges.

Yuan

bug#60256: 29.0.60; Maybe improve tree sitter default treesit-language-at function

[Eli Zaretskii]

tags 60256 wontfix
thanks

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 24 Dec 2022 14:43:18 -0800
> Cc: Wilhelm Hugo Kirschbaum <wilhelm@floatpays.co.za>,
>  60256@debbugs.gnu.org
> 
> 
> Yeah, sorry for the delay. I don’t think it’s worth it, because (1) I
> expect major modes with multiple langauges to implement
> treesit-language-at-point-function which takes care of all the work, and
> (2) in the rare case where there are multiple languages and no
> treesit-language-at-point-function, using the first language whose range
> spans point (this patch) is not necessarily correct: the host language (eg, HTML
> among HTML, CSS & JavaScript) always covers the whole buffer, only
> embedded languages has ranges.

OK, thanks.

bug#60256: 29.0.60; Maybe improve tree sitter default treesit-language-at function

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 60256 wontfix
> thanks
>
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 24 Dec 2022 14:43:18 -0800
>> Cc: Wilhelm Hugo Kirschbaum <wilhelm@floatpays.co.za>,
>>  60256@debbugs.gnu.org
>>
>>
>> Yeah, sorry for the delay. I don’t think it’s worth it, because (1) I
>> expect major modes with multiple langauges to implement
>> treesit-language-at-point-function which takes care of all the work, and
>> (2) in the rare case where there are multiple languages and no
>> treesit-language-at-point-function, using the first language whose range
>> spans point (this patch) is not necessarily correct: the host language (eg, HTML
>> among HTML, CSS & JavaScript) always covers the whole buffer, only
>> embedded languages has ranges.
>
> OK, thanks.

I'm therefore closing this bug report.