GNU bug report logs - #60961
29.0.60; Compiling emacs-29 without treesitter outputs warnings

Previous Next

Package: emacs;

Reported by: Robert Pluim <rpluim <at> gmail.com>

Date: Fri, 20 Jan 2023 10:31:01 UTC

Severity: normal

Found in version 29.0.60

Fixed in versions 30.1, 29.1

Done: Theodor Thornhill <theo <at> thornhill.no>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 10:31:02 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
Date: Fri, 20 Jan 2023 11:30:33 +0100
This is emacs-29 as of 6b2f85caa6c

  ELC      progmodes/csharp-mode.elc
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  ELC      progmodes/dockerfile-ts-mode.elc
  ELC      progmodes/go-ts-mode.elc
  ELC      progmodes/java-ts-mode.elc
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  ELC      progmodes/js.elc
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  ELC      progmodes/json-ts-mode.elc
  ELC      progmodes/python.elc
  ELC      progmodes/ruby-mode.elc
  ELC      progmodes/ruby-ts-mode.elc
  ELC      progmodes/rust-ts-mode.elc
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  ELC      progmodes/typescript-ts-mode.elc
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
  Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs

In GNU Emacs 29.0.60 (build 38, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2023-01-19 built on rltb
Repository revision: faee7e1f1bd0167e455a0e1e5fe02e21d23fd77f
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-x-toolkit=lucid'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Robert
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 13:37:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>, Yuan Fu <casouri <at> gmail.com>,
 Theodor Thornhill <theo <at> thornhill.no>
Cc: 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60;
 Compiling emacs-29 without treesitter outputs warnings
Date: Fri, 20 Jan 2023 15:36:27 +0200
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Fri, 20 Jan 2023 11:30:33 +0100
> 
> 
> This is emacs-29 as of 6b2f85caa6c
> 
>   ELC      progmodes/csharp-mode.elc
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   ELC      progmodes/dockerfile-ts-mode.elc
>   ELC      progmodes/go-ts-mode.elc
>   ELC      progmodes/java-ts-mode.elc
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   ELC      progmodes/js.elc
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   ELC      progmodes/json-ts-mode.elc
>   ELC      progmodes/python.elc
>   ELC      progmodes/ruby-mode.elc
>   ELC      progmodes/ruby-ts-mode.elc
>   ELC      progmodes/rust-ts-mode.elc
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   ELC      progmodes/typescript-ts-mode.elc
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs

Yes, I've seen these as well.  The reason is that some modes 'require'
c-ts-mode, because they want to use their comment-related functions.
But the changes I made recently call treesit-ready-p when c-ts-mode is
being loaded, and that emits the warning.  I can shut up the warning
by calling treesit-ready-p with a non-nil QUIET argument, but then the
warning will not be emitted if users load c-ts-mode from their init
files or manually, which is not good.  I tried several other
solutions, but they either didn't work or were not clean enough for my
palate.

Yuan/Theo, please find a solution for this.  If no better idea comes
up, I think the c-ts-mode functions that other modes want to use
should be moved to a separate file, and that file that can be
'require'd by all those which want it, including by c-ts-mode.el.

TIA.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 13:51:02 GMT) Full text and rfc822 format available.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>, Yuan Fu
 <casouri <at> gmail.com>
Cc: 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter
 outputs warnings
Date: Fri, 20 Jan 2023 14:50:22 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Robert Pluim <rpluim <at> gmail.com>
>> Date: Fri, 20 Jan 2023 11:30:33 +0100
>> 
>> 
>> This is emacs-29 as of 6b2f85caa6c
>> 
>>   ELC      progmodes/csharp-mode.elc
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   ELC      progmodes/dockerfile-ts-mode.elc
>>   ELC      progmodes/go-ts-mode.elc
>>   ELC      progmodes/java-ts-mode.elc
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   ELC      progmodes/js.elc
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   ELC      progmodes/json-ts-mode.elc
>>   ELC      progmodes/python.elc
>>   ELC      progmodes/ruby-mode.elc
>>   ELC      progmodes/ruby-ts-mode.elc
>>   ELC      progmodes/rust-ts-mode.elc
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   ELC      progmodes/typescript-ts-mode.elc
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>>   Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
>
> Yes, I've seen these as well.  The reason is that some modes 'require'
> c-ts-mode, because they want to use their comment-related functions.
> But the changes I made recently call treesit-ready-p when c-ts-mode is
> being loaded, and that emits the warning.  I can shut up the warning
> by calling treesit-ready-p with a non-nil QUIET argument, but then the
> warning will not be emitted if users load c-ts-mode from their init
> files or manually, which is not good.  I tried several other
> solutions, but they either didn't work or were not clean enough for my
> palate.
>
> Yuan/Theo, please find a solution for this.  If no better idea comes
> up, I think the c-ts-mode functions that other modes want to use
> should be moved to a separate file, and that file that can be
> 'require'd by all those which want it, including by c-ts-mode.el.
>

Yeah, I was hoping to actually just allowing some duplication of code,
until some "best practice" emerges the coming months, and we can make a
treesit-common-lib.el or something like that.

So I can either just make sure that no modes require across modes, or
make that "lib" right now.  What do you think?

Theo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 14:17:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter
 outputs warnings
Date: Fri, 20 Jan 2023 16:15:57 +0200
> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: 60961 <at> debbugs.gnu.org
> Date: Fri, 20 Jan 2023 14:50:22 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Yes, I've seen these as well.  The reason is that some modes 'require'
> > c-ts-mode, because they want to use their comment-related functions.
> > But the changes I made recently call treesit-ready-p when c-ts-mode is
> > being loaded, and that emits the warning.  I can shut up the warning
> > by calling treesit-ready-p with a non-nil QUIET argument, but then the
> > warning will not be emitted if users load c-ts-mode from their init
> > files or manually, which is not good.  I tried several other
> > solutions, but they either didn't work or were not clean enough for my
> > palate.
> >
> > Yuan/Theo, please find a solution for this.  If no better idea comes
> > up, I think the c-ts-mode functions that other modes want to use
> > should be moved to a separate file, and that file that can be
> > 'require'd by all those which want it, including by c-ts-mode.el.
> >
> 
> Yeah, I was hoping to actually just allowing some duplication of code,
> until some "best practice" emerges the coming months, and we can make a
> treesit-common-lib.el or something like that.
> 
> So I can either just make sure that no modes require across modes, or
> make that "lib" right now.  What do you think?

I tend to the "lib" method.  Mostly because several modes, including
some that are unrelated to C, want the code which was written for
C/C++, and so it is possible that there's some general feature here
waiting for us to refactor the code -- in which case perhaps the code
should be in treesit.el?

IOW, how come JS, Rust, and Typescript all want comment-related setup
that was written for C?  If this is just a coincidence, then perhaps
duplicating the code is a better idea, but if there's some underlying
commonality, we should have common code in treesit.el, or maybe in
some c-ts-common.el?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 14:44:02 GMT) Full text and rfc822 format available.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter
 outputs warnings
Date: Fri, 20 Jan 2023 15:43:33 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: 60961 <at> debbugs.gnu.org
>> Date: Fri, 20 Jan 2023 14:50:22 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Yes, I've seen these as well.  The reason is that some modes 'require'
>> > c-ts-mode, because they want to use their comment-related functions.
>> > But the changes I made recently call treesit-ready-p when c-ts-mode is
>> > being loaded, and that emits the warning.  I can shut up the warning
>> > by calling treesit-ready-p with a non-nil QUIET argument, but then the
>> > warning will not be emitted if users load c-ts-mode from their init
>> > files or manually, which is not good.  I tried several other
>> > solutions, but they either didn't work or were not clean enough for my
>> > palate.
>> >
>> > Yuan/Theo, please find a solution for this.  If no better idea comes
>> > up, I think the c-ts-mode functions that other modes want to use
>> > should be moved to a separate file, and that file that can be
>> > 'require'd by all those which want it, including by c-ts-mode.el.
>> >
>> 
>> Yeah, I was hoping to actually just allowing some duplication of code,
>> until some "best practice" emerges the coming months, and we can make a
>> treesit-common-lib.el or something like that.
>> 
>> So I can either just make sure that no modes require across modes, or
>> make that "lib" right now.  What do you think?
>
> I tend to the "lib" method.  Mostly because several modes, including
> some that are unrelated to C, want the code which was written for
> C/C++, and so it is possible that there's some general feature here
> waiting for us to refactor the code -- in which case perhaps the code
> should be in treesit.el?
>
> IOW, how come JS, Rust, and Typescript all want comment-related setup
> that was written for C?  If this is just a coincidence, then perhaps
> duplicating the code is a better idea, but if there's some underlying
> commonality, we should have common code in treesit.el, or maybe in
> some c-ts-common.el?

I can start by moving it into treesit.el, then we can maybe extract
something out later.  Sounds good?  I can do it tonight, unless any of
you object :)

Theo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 15:18:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter
 outputs warnings
Date: Fri, 20 Jan 2023 17:17:22 +0200
> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
> Date: Fri, 20 Jan 2023 15:43:33 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> So I can either just make sure that no modes require across modes, or
> >> make that "lib" right now.  What do you think?
> >
> > I tend to the "lib" method.  Mostly because several modes, including
> > some that are unrelated to C, want the code which was written for
> > C/C++, and so it is possible that there's some general feature here
> > waiting for us to refactor the code -- in which case perhaps the code
> > should be in treesit.el?
> >
> > IOW, how come JS, Rust, and Typescript all want comment-related setup
> > that was written for C?  If this is just a coincidence, then perhaps
> > duplicating the code is a better idea, but if there's some underlying
> > commonality, we should have common code in treesit.el, or maybe in
> > some c-ts-common.el?
> 
> I can start by moving it into treesit.el, then we can maybe extract
> something out later.  Sounds good?  I can do it tonight, unless any of
> you object :)

SGTM, but let's hear from Yuan before you start working on this.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 16:09:01 GMT) Full text and rfc822 format available.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
Date: Fri, 20 Jan 2023 17:07:28 +0100

On 20 January 2023 16:17:22 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
>> Date: Fri, 20 Jan 2023 15:43:33 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> So I can either just make sure that no modes require across modes, or
>> >> make that "lib" right now.  What do you think?
>> >
>> > I tend to the "lib" method.  Mostly because several modes, including
>> > some that are unrelated to C, want the code which was written for
>> > C/C++, and so it is possible that there's some general feature here
>> > waiting for us to refactor the code -- in which case perhaps the code
>> > should be in treesit.el?
>> >
>> > IOW, how come JS, Rust, and Typescript all want comment-related setup
>> > that was written for C?  If this is just a coincidence, then perhaps
>> > duplicating the code is a better idea, but if there's some underlying
>> > commonality, we should have common code in treesit.el, or maybe in
>> > some c-ts-common.el?
>> 
>> I can start by moving it into treesit.el, then we can maybe extract
>> something out later.  Sounds good?  I can do it tonight, unless any of
>> you object :)
>
>SGTM, but let's hear from Yuan before you start working on this.
>
>Thanks.

Thumbs up




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 22:13:01 GMT) Full text and rfc822 format available.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs
 warnings
Date: Fri, 20 Jan 2023 14:11:44 -0800

> On Jan 20, 2023, at 8:07 AM, Theodor Thornhill <theo <at> thornhill.no> wrote:
> 
> 
> 
> On 20 January 2023 16:17:22 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> From: Theodor Thornhill <theo <at> thornhill.no>
>>> Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
>>> Date: Fri, 20 Jan 2023 15:43:33 +0100
>>> 
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> 
>>>>> So I can either just make sure that no modes require across modes, or
>>>>> make that "lib" right now.  What do you think?
>>>> 
>>>> I tend to the "lib" method.  Mostly because several modes, including
>>>> some that are unrelated to C, want the code which was written for
>>>> C/C++, and so it is possible that there's some general feature here
>>>> waiting for us to refactor the code -- in which case perhaps the code
>>>> should be in treesit.el?
>>>> 
>>>> IOW, how come JS, Rust, and Typescript all want comment-related setup
>>>> that was written for C?

Because they all have C-like syntax, so they have the same setup for indenting and filling block comments, for example.

>>>>  If this is just a coincidence, then perhaps
>>>> duplicating the code is a better idea, but if there's some underlying
>>>> commonality, we should have common code in treesit.el, or maybe in
>>>> some c-ts-common.el?

c-ts-common.el sounds good to me.

>>> 
>>> I can start by moving it into treesit.el, then we can maybe extract
>>> something out later.  Sounds good?  I can do it tonight, unless any of
>>> you object :)
>> 
>> SGTM, but let's hear from Yuan before you start working on this.
>> 
>> Thanks.
> 
> Thumbs up

I’d prefer c-ts-common.el over treesit.el, since they only apply to C-like languages. There is no harm putting them in a separate file, right? I wrote some commentary in c-ts-mode, which notes all the shared functions and variables. 

Yuan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 22:31:01 GMT) Full text and rfc822 format available.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
Date: Fri, 20 Jan 2023 23:30:41 +0100

On 20 January 2023 23:11:44 CET, Yuan Fu <casouri <at> gmail.com> wrote:
>
>
>> On Jan 20, 2023, at 8:07 AM, Theodor Thornhill <theo <at> thornhill.no> wrote:
>> 
>> 
>> 
>> On 20 January 2023 16:17:22 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> From: Theodor Thornhill <theo <at> thornhill.no>
>>>> Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
>>>> Date: Fri, 20 Jan 2023 15:43:33 +0100
>>>> 
>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>> 
>>>>>> So I can either just make sure that no modes require across modes, or
>>>>>> make that "lib" right now.  What do you think?
>>>>> 
>>>>> I tend to the "lib" method.  Mostly because several modes, including
>>>>> some that are unrelated to C, want the code which was written for
>>>>> C/C++, and so it is possible that there's some general feature here
>>>>> waiting for us to refactor the code -- in which case perhaps the code
>>>>> should be in treesit.el?
>>>>> 
>>>>> IOW, how come JS, Rust, and Typescript all want comment-related setup
>>>>> that was written for C?
>
>Because they all have C-like syntax, so they have the same setup for indenting and filling block comments, for example.
>
>>>>>  If this is just a coincidence, then perhaps
>>>>> duplicating the code is a better idea, but if there's some underlying
>>>>> commonality, we should have common code in treesit.el, or maybe in
>>>>> some c-ts-common.el?
>
>c-ts-common.el sounds good to me.
>
>>>> 
>>>> I can start by moving it into treesit.el, then we can maybe extract
>>>> something out later.  Sounds good?  I can do it tonight, unless any of
>>>> you object :)
>>> 
>>> SGTM, but let's hear from Yuan before you start working on this.
>>> 
>>> Thanks.
>> 
>> Thumbs up
>
>I’d prefer c-ts-common.el over treesit.el, since they only apply to C-like languages. There is no harm putting them in a separate file, right? I wrote some commentary in c-ts-mode, which notes all the shared functions and variables. 
>
>Yuan
>

Ok, should I do it or you? :)

Theo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Fri, 20 Jan 2023 22:37:01 GMT) Full text and rfc822 format available.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>,
 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs
 warnings
Date: Fri, 20 Jan 2023 14:36:00 -0800

> On Jan 20, 2023, at 2:30 PM, Theodor Thornhill <theo <at> thornhill.no> wrote:
> 
> 
> 
> On 20 January 2023 23:11:44 CET, Yuan Fu <casouri <at> gmail.com> wrote:
>> 
>> 
>>> On Jan 20, 2023, at 8:07 AM, Theodor Thornhill <theo <at> thornhill.no> wrote:
>>> 
>>> 
>>> 
>>> On 20 January 2023 16:17:22 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>>> From: Theodor Thornhill <theo <at> thornhill.no>
>>>>> Cc: rpluim <at> gmail.com, casouri <at> gmail.com, 60961 <at> debbugs.gnu.org
>>>>> Date: Fri, 20 Jan 2023 15:43:33 +0100
>>>>> 
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>>> 
>>>>>>> So I can either just make sure that no modes require across modes, or
>>>>>>> make that "lib" right now.  What do you think?
>>>>>> 
>>>>>> I tend to the "lib" method.  Mostly because several modes, including
>>>>>> some that are unrelated to C, want the code which was written for
>>>>>> C/C++, and so it is possible that there's some general feature here
>>>>>> waiting for us to refactor the code -- in which case perhaps the code
>>>>>> should be in treesit.el?
>>>>>> 
>>>>>> IOW, how come JS, Rust, and Typescript all want comment-related setup
>>>>>> that was written for C?
>> 
>> Because they all have C-like syntax, so they have the same setup for indenting and filling block comments, for example.
>> 
>>>>>> If this is just a coincidence, then perhaps
>>>>>> duplicating the code is a better idea, but if there's some underlying
>>>>>> commonality, we should have common code in treesit.el, or maybe in
>>>>>> some c-ts-common.el?
>> 
>> c-ts-common.el sounds good to me.
>> 
>>>>> 
>>>>> I can start by moving it into treesit.el, then we can maybe extract
>>>>> something out later.  Sounds good?  I can do it tonight, unless any of
>>>>> you object :)
>>>> 
>>>> SGTM, but let's hear from Yuan before you start working on this.
>>>> 
>>>> Thanks.
>>> 
>>> Thumbs up
>> 
>> I’d prefer c-ts-common.el over treesit.el, since they only apply to C-like languages. There is no harm putting them in a separate file, right? I wrote some commentary in c-ts-mode, which notes all the shared functions and variables. 
>> 
>> Yuan
>> 
> 
> Ok, should I do it or you? :)
> 
> Theo

The honor is yours :-)

Yuan



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Sat, 21 Jan 2023 04:19:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: rpluim <at> gmail.com, theo <at> thornhill.no, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs
 warnings
Date: Sat, 21 Jan 2023 06:18:51 +0200
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Fri, 20 Jan 2023 14:11:44 -0800
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  rpluim <at> gmail.com,
>  60961 <at> debbugs.gnu.org
> 
> I’d prefer c-ts-common.el over treesit.el, since they only apply to C-like languages. There is no harm putting them in a separate file, right? I wrote some commentary in c-ts-mode, which notes all the shared functions and variables. 

c-ts-common.el SGTM, thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Sat, 21 Jan 2023 12:25:01 GMT) Full text and rfc822 format available.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>
Cc: rpluim <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter
 outputs warnings
Date: Sat, 21 Jan 2023 13:24:12 +0100
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Fri, 20 Jan 2023 14:11:44 -0800
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>>  rpluim <at> gmail.com,
>>  60961 <at> debbugs.gnu.org
>> 
>> I’d prefer c-ts-common.el over treesit.el, since they only apply to C-like languages. There is no harm putting them in a separate file, right? I wrote some commentary in c-ts-mode, which notes all the shared functions and variables. 
>
> c-ts-common.el SGTM, thanks.

Something like this?  I get no warnings on tree-sitter-less build on
emacs-29 now.
Do we need anything in NEWS or anywhere else?

Theo

[0001-Move-c-like-common-utils-into-own-library-bug-60961.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Sat, 21 Jan 2023 12:39:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: casouri <at> gmail.com, rpluim <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter
 outputs warnings
Date: Sat, 21 Jan 2023 14:38:16 +0200
> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: rpluim <at> gmail.com, 60961 <at> debbugs.gnu.org
> Date: Sat, 21 Jan 2023 13:24:12 +0100
> 
> > c-ts-common.el SGTM, thanks.
> 
> Something like this?  I get no warnings on tree-sitter-less build on
> emacs-29 now.

Yes, thanks.

> Do we need anything in NEWS or anywhere else?

No, this is an internal implementation issue.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60961; Package emacs. (Sat, 21 Jan 2023 12:47:02 GMT) Full text and rfc822 format available.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, rpluim <at> gmail.com, 60961 <at> debbugs.gnu.org
Subject: Re: bug#60961: 29.0.60; Compiling emacs-29 without treesitter
 outputs warnings
Date: Sat, 21 Jan 2023 13:46:49 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: rpluim <at> gmail.com, 60961 <at> debbugs.gnu.org
>> Date: Sat, 21 Jan 2023 13:24:12 +0100
>> 
>> > c-ts-common.el SGTM, thanks.
>> 
>> Something like this?  I get no warnings on tree-sitter-less build on
>> emacs-29 now.
>
> Yes, thanks.
>

No problem.

>> Do we need anything in NEWS or anywhere else?
>
> No, this is an internal implementation issue.

Ok, installing it later today, then, unless anyone else objects.

Thanks,

Theo





bug Marked as fixed in versions 30.1. Request was from Theodor Thornhill <theo <at> thornhill.no> to control <at> debbugs.gnu.org. (Sat, 21 Jan 2023 20:43:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 29.1, send any further explanations to 60961 <at> debbugs.gnu.org and Robert Pluim <rpluim <at> gmail.com> Request was from Theodor Thornhill <theo <at> thornhill.no> to control <at> debbugs.gnu.org. (Sat, 04 Feb 2023 08:27:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 04 Mar 2023 12:24:15 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 26 days ago.

Previous Next


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