GNU bug report logs - #60256
29.0.60; Maybe improve tree sitter default treesit-language-at function

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60256 in the body.
You can then email your comments to 60256 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Wilhelm H Kirschbaum <wilhelm <at> floatpays.co.za>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; Maybe improve tree sitter default treesit-language-at
 function
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?

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

Message #8 received at 60256 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Wilhelm H Kirschbaum <wilhelm <at> floatpays.co.za>, Yuan Fu <casouri <at> gmail.com>
Cc: 60256 <at> debbugs.gnu.org
Subject: Re: bug#60256: 29.0.60;
 Maybe improve tree sitter default treesit-language-at function
Date: Sat, 24 Dec 2022 09:25:12 +0200

> From: Wilhelm H Kirschbaum <wilhelm <at> 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?

Message #11 received at 60256 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60256 <at> debbugs.gnu.org, Wilhelm Hugo Kirschbaum <wilhelm <at> floatpays.co.za>
Subject: Re: bug#60256: 29.0.60; Maybe improve tree sitter default 
 treesit-language-at function
Date: Sat, 24 Dec 2022 14:43:18 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Wilhelm H Kirschbaum <wilhelm <at> 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

Message #14 received at 60256 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 60256 <at> debbugs.gnu.org, wilhelm <at> floatpays.co.za
Subject: Re: bug#60256: 29.0.60; Maybe improve tree sitter default 
 treesit-language-at function
Date: Sun, 25 Dec 2022 08:40:35 +0200

tags 60256 wontfix
thanks

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sat, 24 Dec 2022 14:43:18 -0800
> Cc: Wilhelm Hugo Kirschbaum <wilhelm <at> floatpays.co.za>,
>  60256 <at> 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.

Message #21 received at 60256-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Yuan Fu <casouri <at> gmail.com>, 60256-done <at> debbugs.gnu.org,
 wilhelm <at> floatpays.co.za
Subject: Re: bug#60256: 29.0.60; Maybe improve tree sitter default
 treesit-language-at function
Date: Sat, 2 Sep 2023 09:41:05 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 60256 wontfix
> thanks
>
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Sat, 24 Dec 2022 14:43:18 -0800
>> Cc: Wilhelm Hugo Kirschbaum <wilhelm <at> floatpays.co.za>,
>>  60256 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.