GNU bug report logs -
#60961
29.0.60; Compiling emacs-29 without treesitter outputs warnings
Previous Next
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.
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):
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: 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):
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: 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):
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: 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):
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):
> 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):
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):
> 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: 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):
[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: 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):
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.