* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
@ 2023-01-20 10:30 Robert Pluim
2023-01-20 13:36 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Robert Pluim @ 2023-01-20 10:30 UTC (permalink / raw)
To: 60961
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
--
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 10:30 bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings Robert Pluim
@ 2023-01-20 13:36 ` Eli Zaretskii
2023-01-20 13:50 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2023-01-20 13:36 UTC (permalink / raw)
To: Robert Pluim, Yuan Fu, Theodor Thornhill; +Cc: 60961
> From: Robert Pluim <rpluim@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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 13:36 ` Eli Zaretskii
@ 2023-01-20 13:50 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-20 14:15 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-20 13:50 UTC (permalink / raw)
To: Eli Zaretskii, Robert Pluim, Yuan Fu; +Cc: 60961
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Robert Pluim <rpluim@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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 13:50 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-01-20 14:15 ` Eli Zaretskii
2023-01-20 14:43 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2023-01-20 14:15 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: rpluim, casouri, 60961
> From: Theodor Thornhill <theo@thornhill.no>
> Cc: 60961@debbugs.gnu.org
> Date: Fri, 20 Jan 2023 14:50:22 +0100
>
> Eli Zaretskii <eliz@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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 14:15 ` Eli Zaretskii
@ 2023-01-20 14:43 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-20 15:17 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-20 14:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rpluim, casouri, 60961
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: 60961@debbugs.gnu.org
>> Date: Fri, 20 Jan 2023 14:50:22 +0100
>>
>> Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 14:43 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-01-20 15:17 ` Eli Zaretskii
2023-01-20 16:07 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2023-01-20 15:17 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: rpluim, casouri, 60961
> From: Theodor Thornhill <theo@thornhill.no>
> Cc: rpluim@gmail.com, casouri@gmail.com, 60961@debbugs.gnu.org
> Date: Fri, 20 Jan 2023 15:43:33 +0100
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 15:17 ` Eli Zaretskii
@ 2023-01-20 16:07 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-20 22:11 ` Yuan Fu
0 siblings, 1 reply; 14+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-20 16:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rpluim, casouri, 60961
On 20 January 2023 16:17:22 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: rpluim@gmail.com, casouri@gmail.com, 60961@debbugs.gnu.org
>> Date: Fri, 20 Jan 2023 15:43:33 +0100
>>
>> Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 16:07 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-01-20 22:11 ` Yuan Fu
2023-01-20 22:30 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-21 4:18 ` Eli Zaretskii
0 siblings, 2 replies; 14+ messages in thread
From: Yuan Fu @ 2023-01-20 22:11 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: Eli Zaretskii, rpluim, 60961
> On Jan 20, 2023, at 8:07 AM, Theodor Thornhill <theo@thornhill.no> wrote:
>
>
>
> On 20 January 2023 16:17:22 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Theodor Thornhill <theo@thornhill.no>
>>> Cc: rpluim@gmail.com, casouri@gmail.com, 60961@debbugs.gnu.org
>>> Date: Fri, 20 Jan 2023 15:43:33 +0100
>>>
>>> Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 22:11 ` Yuan Fu
@ 2023-01-20 22:30 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-20 22:36 ` Yuan Fu
2023-01-21 4:18 ` Eli Zaretskii
1 sibling, 1 reply; 14+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-20 22:30 UTC (permalink / raw)
To: Yuan Fu; +Cc: Eli Zaretskii, rpluim, 60961
On 20 January 2023 23:11:44 CET, Yuan Fu <casouri@gmail.com> wrote:
>
>
>> On Jan 20, 2023, at 8:07 AM, Theodor Thornhill <theo@thornhill.no> wrote:
>>
>>
>>
>> On 20 January 2023 16:17:22 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> From: Theodor Thornhill <theo@thornhill.no>
>>>> Cc: rpluim@gmail.com, casouri@gmail.com, 60961@debbugs.gnu.org
>>>> Date: Fri, 20 Jan 2023 15:43:33 +0100
>>>>
>>>> Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 22:30 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-01-20 22:36 ` Yuan Fu
0 siblings, 0 replies; 14+ messages in thread
From: Yuan Fu @ 2023-01-20 22:36 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: Eli Zaretskii, Robert Pluim, 60961
> On Jan 20, 2023, at 2:30 PM, Theodor Thornhill <theo@thornhill.no> wrote:
>
>
>
> On 20 January 2023 23:11:44 CET, Yuan Fu <casouri@gmail.com> wrote:
>>
>>
>>> On Jan 20, 2023, at 8:07 AM, Theodor Thornhill <theo@thornhill.no> wrote:
>>>
>>>
>>>
>>> On 20 January 2023 16:17:22 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>> From: Theodor Thornhill <theo@thornhill.no>
>>>>> Cc: rpluim@gmail.com, casouri@gmail.com, 60961@debbugs.gnu.org
>>>>> Date: Fri, 20 Jan 2023 15:43:33 +0100
>>>>>
>>>>> Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-20 22:11 ` Yuan Fu
2023-01-20 22:30 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-01-21 4:18 ` Eli Zaretskii
2023-01-21 12:24 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2023-01-21 4:18 UTC (permalink / raw)
To: Yuan Fu; +Cc: rpluim, theo, 60961
> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 20 Jan 2023 14:11:44 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>,
> rpluim@gmail.com,
> 60961@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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-21 4:18 ` Eli Zaretskii
@ 2023-01-21 12:24 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-21 12:38 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-21 12:24 UTC (permalink / raw)
To: Eli Zaretskii, Yuan Fu; +Cc: rpluim, 60961
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Fri, 20 Jan 2023 14:11:44 -0800
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> rpluim@gmail.com,
>> 60961@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
[-- Attachment #2: 0001-Move-c-like-common-utils-into-own-library-bug-60961.patch --]
[-- Type: text/x-patch, Size: 30184 bytes --]
From b7f7b135cf42d9de73c83ba953e3e149dde19f0f Mon Sep 17 00:00:00 2001
From: Theodor Thornhill <theo@thornhill.no>
Date: Sat, 21 Jan 2023 12:24:55 +0100
Subject: [PATCH] Move c-like common utils into own library (bug#60961)
* lisp/progmodes/c-ts-common.el: New file.
* lisp/progmodes/c-ts-mode.el (treesit-induce-sparse-tree): Remove
unused declaration.
(c-ts-mode--indent-styles): Refer to the new library.
(c-ts-mode--looking-at-star,
c-ts-mode--comment-start-after-first-star,
c-ts-mode--comment-2nd-line-matcher,
c-ts-mode--comment-2nd-line-anchor, c-ts-mode--comment-regexp,
c-ts-mode--fill-paragraph, c-ts-mode--fill-block-comment): Move to
c-ts-common and expose as public.
(c-ts-mode-comment-setup): Move to c-ts-common.
* lisp/progmodes/csharp-mode.el (c-ts-common): Require new library.
(csharp-ts-mode--indent-rules): Refer to the new symbols.
(csharp-ts-mode): Use new function.
* lisp/progmodes/java-ts-mode.el (c-ts-common): Require new library.
(java-ts-mode--indent-rules): Refer to the new symbols.
(java-ts-mode): Use new function.
* lisp/progmodes/js.el (c-ts-common): Require new library.
(js--treesit-indent-rules): Refer to the new symbols.
(js-ts-mode): Use new function.
* lisp/progmodes/rust-ts-mode.el (c-ts-common): Require new library.
(rust-ts-mode--indent-rules): Refer to the new symbols.
(rust-ts-mode): Use new function.
* lisp/progmodes/typescript-ts-mode.el (c-ts-common): Require new
library.
(typescript-ts-mode--indent-rules): Refer to the new symbols.
(typescript-ts-base-mode): Use new function.
---
lisp/progmodes/c-ts-common.el | 247 +++++++++++++++++++++++++++
lisp/progmodes/c-ts-mode.el | 228 +------------------------
lisp/progmodes/csharp-mode.el | 8 +-
lisp/progmodes/java-ts-mode.el | 8 +-
lisp/progmodes/js.el | 8 +-
lisp/progmodes/rust-ts-mode.el | 8 +-
lisp/progmodes/typescript-ts-mode.el | 8 +-
7 files changed, 275 insertions(+), 240 deletions(-)
create mode 100644 lisp/progmodes/c-ts-common.el
diff --git a/lisp/progmodes/c-ts-common.el b/lisp/progmodes/c-ts-common.el
new file mode 100644
index 0000000000..6671d4be5b
--- /dev/null
+++ b/lisp/progmodes/c-ts-common.el
@@ -0,0 +1,247 @@
+;;; c-ts-common.el --- Utilities for C like Languages -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2023 Free Software Foundation, Inc.
+
+;; Author : 付禹安 (Yuan Fu) <casouri@gmail.com>
+;; Keywords : c c++ java javascript rust languages tree-sitter
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+;;
+;; For C-like language major modes:
+;;
+;; - Use `c-ts-common-comment-setup' to setup comment variables and
+;; filling.
+;;
+;; - Use simple-indent matcher `c-ts-common-looking-at-star' and
+;; anchor `c-ts-common-comment-start-after-first-star' for indenting
+;; block comments. See `c-ts-mode--indent-styles' for example.
+
+;;; Code:
+
+(require 'treesit)
+(eval-when-compile (require 'rx))
+
+(declare-function treesit-node-start "treesit.c")
+(declare-function treesit-node-end "treesit.c")
+(declare-function treesit-node-type "treesit.c")
+
+(defun c-ts-common-looking-at-star (_n _p bol &rest _)
+ "A tree-sitter simple indent matcher.
+Matches if there is a \"*\" after BOL."
+ (eq (char-after bol) ?*))
+
+(defun c-ts-common-comment-start-after-first-star (_n parent &rest _)
+ "A tree-sitter simple indent anchor.
+Finds the \"/*\" and returns the point after the \"*\".
+Assumes PARENT is a comment node."
+ (save-excursion
+ (goto-char (treesit-node-start parent))
+ (if (looking-at (rx "/*"))
+ (match-end 0)
+ (point))))
+
+(defun c-ts-common-comment-2nd-line-matcher (_n parent &rest _)
+ "Matches if point is at the second line of a block comment.
+PARENT should be a comment node."
+ (and (equal (treesit-node-type parent) "comment")
+ (save-excursion
+ (forward-line -1)
+ (back-to-indentation)
+ (eq (point) (treesit-node-start parent)))))
+
+(defun c-ts-common-comment-2nd-line-anchor (_n _p bol &rest _)
+ "Return appropriate anchor for the second line of a comment.
+
+If the first line is /* alone, return the position right after
+the star; if the first line is /* followed by some text, return
+the position right before the text minus 1.
+
+Use an offset of 1 with this anchor. BOL is the beginning of
+non-whitespace characters of the current line."
+ (save-excursion
+ (forward-line -1)
+ (back-to-indentation)
+ (when (looking-at comment-start-skip)
+ (goto-char (match-end 0))
+ (if (looking-at (rx (* (or " " "\t")) eol))
+ ;; Only /* at the first line.
+ (progn (skip-chars-backward " \t")
+ (if (save-excursion
+ (goto-char bol)
+ (looking-at (rx "*")))
+ ;; The common case. Checked by "Multiline Block
+ ;; Comments 4".
+ (point)
+ ;; The "Multiline Block Comments 2" test in
+ ;; c-ts-common-resources/indent.erts checks this.
+ (1- (point))))
+ ;; There is something after /* at the first line. The
+ ;; "Multiline Block Comments 3" test checks this.
+ (1- (point))))))
+
+(defvar c-ts-common--comment-regexp
+ ;; These covers C/C++, Java, JavaScript, TypeScript, Rust, C#.
+ (rx (or "comment" "line_comment" "block_comment"))
+ "Regexp pattern that matches a comment in C-like languages.")
+
+(defun c-ts-common--fill-paragraph (&optional arg)
+ "Fillling function for `c-ts-common'.
+ARG is passed to `fill-paragraph'."
+ (interactive "*P")
+ (save-restriction
+ (widen)
+ (let ((node (treesit-node-at (point))))
+ (when (string-match-p c-ts-common--comment-regexp
+ (treesit-node-type node))
+ (if (save-excursion
+ (goto-char (treesit-node-start node))
+ (looking-at "//"))
+ (fill-comment-paragraph arg)
+ (c-ts-common--fill-block-comment arg)))
+ ;; Return t so `fill-paragraph' doesn't attempt to fill by
+ ;; itself.
+ t)))
+
+(defun c-ts-common--fill-block-comment (&optional arg)
+ "Fillling function for block comments.
+ARG is passed to `fill-paragraph'. Assume point is in a block
+comment."
+ (let* ((node (treesit-node-at (point)))
+ (start (treesit-node-start node))
+ (end (treesit-node-end node))
+ ;; Bind to nil to avoid infinite recursion.
+ (fill-paragraph-function nil)
+ (orig-point (point-marker))
+ (start-marker (point-marker))
+ (end-marker nil)
+ (end-len 0))
+ (move-marker start-marker start)
+ ;; We mask "/*" and the space before "*/" like
+ ;; `c-fill-paragraph' does.
+ (atomic-change-group
+ ;; Mask "/*".
+ (goto-char start)
+ (when (looking-at (rx (* (syntax whitespace))
+ (group "/") "*"))
+ (goto-char (match-beginning 1))
+ (move-marker start-marker (point))
+ (replace-match " " nil nil nil 1))
+ ;; Include whitespaces before /*.
+ (goto-char start)
+ (beginning-of-line)
+ (setq start (point))
+ ;; Mask spaces before "*/" if it is attached at the end
+ ;; of a sentence rather than on its own line.
+ (goto-char end)
+ (when (looking-back (rx (not (syntax whitespace))
+ (group (+ (syntax whitespace)))
+ "*/")
+ (line-beginning-position))
+ (goto-char (match-beginning 1))
+ (setq end-marker (point-marker))
+ (setq end-len (- (match-end 1) (match-beginning 1)))
+ (replace-match (make-string end-len ?x)
+ nil nil nil 1))
+ ;; If "*/" is on its own line, don't included it in the
+ ;; filling region.
+ (when (not end-marker)
+ (goto-char end)
+ (when (looking-back (rx "*/") 2)
+ (backward-char 2)
+ (skip-syntax-backward "-")
+ (setq end (point))))
+ ;; Let `fill-paragraph' do its thing.
+ (goto-char orig-point)
+ (narrow-to-region start end)
+ ;; We don't want to fill the region between START and
+ ;; START-MARKER, otherwise the filling function might delete
+ ;; some spaces there.
+ (fill-region start-marker end arg)
+ ;; Unmask.
+ (when start-marker
+ (goto-char start-marker)
+ (delete-char 1)
+ (insert "/"))
+ (when end-marker
+ (goto-char end-marker)
+ (delete-region (point) (+ end-len (point)))
+ (insert (make-string end-len ?\s))))))
+
+(defun c-ts-common-comment-setup ()
+ "Set up local variables for C-like comment.
+
+Set up:
+ - `comment-start'
+ - `comment-end'
+ - `comment-start-skip'
+ - `comment-end-skip'
+ - `adaptive-fill-mode'
+ - `adaptive-fill-first-line-regexp'
+ - `paragraph-start'
+ - `paragraph-separate'
+ - `fill-paragraph-function'"
+ (setq-local comment-start "// ")
+ (setq-local comment-end "")
+ (setq-local comment-start-skip (rx (or (seq "/" (+ "/"))
+ (seq "/" (+ "*")))
+ (* (syntax whitespace))))
+ (setq-local comment-end-skip
+ (rx (* (syntax whitespace))
+ (group (or (syntax comment-end)
+ (seq (+ "*") "/")))))
+ (setq-local adaptive-fill-mode t)
+ ;; This matches (1) empty spaces (the default), (2) "//", (3) "*",
+ ;; but do not match "/*", because we don't want to use "/*" as
+ ;; prefix when filling. (Actually, it doesn't matter, because
+ ;; `comment-start-skip' matches "/*" which will cause
+ ;; `fill-context-prefix' to use "/*" as a prefix for filling, that's
+ ;; why we mask the "/*" in `c-ts-common--fill-paragraph'.)
+ (setq-local adaptive-fill-regexp
+ (concat (rx (* (syntax whitespace))
+ (group (or (seq "/" (+ "/")) (* "*"))))
+ adaptive-fill-regexp))
+ ;; Note the missing * comparing to `adaptive-fill-regexp'. The
+ ;; reason for its absence is a bit convoluted to explain. Suffice
+ ;; to say that without it, filling a single line paragraph that
+ ;; starts with /* doesn't insert * at the beginning of each
+ ;; following line, and filling a multi-line paragraph whose first
+ ;; two lines start with * does insert * at the beginning of each
+ ;; following line. If you know how does adaptive filling works, you
+ ;; know what I mean.
+ (setq-local adaptive-fill-first-line-regexp
+ (rx bos
+ (seq (* (syntax whitespace))
+ (group (seq "/" (+ "/")))
+ (* (syntax whitespace)))
+ eos))
+ ;; Same as `adaptive-fill-regexp'.
+ (setq-local paragraph-start
+ (rx (or (seq (* (syntax whitespace))
+ (group (or (seq "/" (+ "/")) (* "*")))
+ (* (syntax whitespace))
+ ;; Add this eol so that in
+ ;; `fill-context-prefix', `paragraph-start'
+ ;; doesn't match the prefix.
+ eol)
+ "\f")))
+ (setq-local paragraph-separate paragraph-start)
+ (setq-local fill-paragraph-function #'c-ts-common--fill-paragraph))
+
+(provide 'c-ts-common)
+
+;;; c-ts-common.el ends here
diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 8ddd622a05..03793d61ba 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -64,26 +64,18 @@
;; files, provided that you have the corresponding parser grammar
;; libraries installed.
;;
-;; For C-like language major modes:
-;;
-;; - Use `c-ts-mode-comment-setup' to setup comment variables and
-;; filling.
-;;
-;; - Use simple-indent matcher `c-ts-mode--looking-at-star' and anchor
-;; `c-ts-mode--comment-start-after-first-star' for indenting block
-;; comments. See `c-ts-mode--indent-styles' for example.
-;;
;; - Use variable `c-ts-mode-indent-block-type-regexp' with indent
;; offset c-ts-mode--statement-offset for indenting statements.
;; Again, see `c-ts-mode--indent-styles' for example.
+;;
;;; Code:
(require 'treesit)
+(require 'c-ts-common)
(eval-when-compile (require 'rx))
(declare-function treesit-parser-create "treesit.c")
-(declare-function treesit-induce-sparse-tree "treesit.c")
(declare-function treesit-node-parent "treesit.c")
(declare-function treesit-node-start "treesit.c")
(declare-function treesit-node-end "treesit.c")
@@ -173,12 +165,12 @@ c-ts-mode--indent-styles
((node-is "else") parent-bol 0)
((node-is "case") parent-bol 0)
((node-is "preproc_arg") no-indent)
- ;; `c-ts-mode--looking-at-star' has to come before
- ;; `c-ts-mode--comment-2nd-line-matcher'.
+ ;; `c-ts-common-looking-at-star' has to come before
+ ;; `c-ts-common-comment-2nd-line-matcher'.
((and (parent-is "comment") c-ts-mode--looking-at-star)
- c-ts-mode--comment-start-after-first-star -1)
- (c-ts-mode--comment-2nd-line-matcher
- c-ts-mode--comment-2nd-line-anchor
+ c-ts-common-comment-start-after-first-star -1)
+ (c-ts-common-comment-2nd-line-matcher
+ c-ts-common-comment-2nd-line-anchor
1)
((parent-is "comment") prev-adaptive-prefix 0)
@@ -333,60 +325,6 @@ c-ts-mode--close-bracket-offset
(- (c-ts-mode--statement-offset node parent)
c-ts-mode-indent-offset))
-(defun c-ts-mode--looking-at-star (_n _p bol &rest _)
- "A tree-sitter simple indent matcher.
-Matches if there is a \"*\" after BOL."
- (eq (char-after bol) ?*))
-
-(defun c-ts-mode--comment-start-after-first-star (_n parent &rest _)
- "A tree-sitter simple indent anchor.
-Finds the \"/*\" and returns the point after the \"*\".
-Assumes PARENT is a comment node."
- (save-excursion
- (goto-char (treesit-node-start parent))
- (if (looking-at (rx "/*"))
- (match-end 0)
- (point))))
-
-(defun c-ts-mode--comment-2nd-line-matcher (_n parent &rest _)
- "Matches if point is at the second line of a block comment.
-PARENT should be a comment node."
- (and (equal (treesit-node-type parent) "comment")
- (save-excursion
- (forward-line -1)
- (back-to-indentation)
- (eq (point) (treesit-node-start parent)))))
-
-(defun c-ts-mode--comment-2nd-line-anchor (_n _p bol &rest _)
- "Return appropriate anchor for the second line of a comment.
-
-If the first line is /* alone, return the position right after
-the star; if the first line is /* followed by some text, return
-the position right before the text minus 1.
-
-Use an offset of 1 with this anchor. BOL is the beginning of
-non-whitespace characters of the current line."
- (save-excursion
- (forward-line -1)
- (back-to-indentation)
- (when (looking-at comment-start-skip)
- (goto-char (match-end 0))
- (if (looking-at (rx (* (or " " "\t")) eol))
- ;; Only /* at the first line.
- (progn (skip-chars-backward " \t")
- (if (save-excursion
- (goto-char bol)
- (looking-at (rx "*")))
- ;; The common case. Checked by "Multiline Block
- ;; Comments 4".
- (point)
- ;; The "Multiline Block Comments 2" test in
- ;; c-ts-mode-resources/indent.erts checks this.
- (1- (point))))
- ;; There is something after /* at the first line. The
- ;; "Multiline Block Comments 3" test checks this.
- (1- (point))))))
-
;;; Font-lock
(defvar c-ts-mode--preproc-keywords
@@ -782,156 +720,6 @@ c-ts-mode-indent-defun
(treesit-node-end node))
(goto-char orig-point)))
-;;; Filling
-
-(defvar c-ts-mode--comment-regexp
- ;; These covers C/C++, Java, JavaScript, TypeScript, Rust, C#.
- (rx (or "comment" "line_comment" "block_comment"))
- "Regexp pattern that matches a comment in C-like languages.")
-
-(defun c-ts-mode--fill-paragraph (&optional arg)
- "Fillling function for `c-ts-mode'.
-ARG is passed to `fill-paragraph'."
- (interactive "*P")
- (save-restriction
- (widen)
- (let ((node (treesit-node-at (point))))
- (when (string-match-p c-ts-mode--comment-regexp
- (treesit-node-type node))
- (if (save-excursion
- (goto-char (treesit-node-start node))
- (looking-at "//"))
- (fill-comment-paragraph arg)
- (c-ts-mode--fill-block-comment arg)))
- ;; Return t so `fill-paragraph' doesn't attempt to fill by
- ;; itself.
- t)))
-
-(defun c-ts-mode--fill-block-comment (&optional arg)
- "Fillling function for block comments.
-ARG is passed to `fill-paragraph'. Assume point is in a block
-comment."
- (let* ((node (treesit-node-at (point)))
- (start (treesit-node-start node))
- (end (treesit-node-end node))
- ;; Bind to nil to avoid infinite recursion.
- (fill-paragraph-function nil)
- (orig-point (point-marker))
- (start-marker (point-marker))
- (end-marker nil)
- (end-len 0))
- (move-marker start-marker start)
- ;; We mask "/*" and the space before "*/" like
- ;; `c-fill-paragraph' does.
- (atomic-change-group
- ;; Mask "/*".
- (goto-char start)
- (when (looking-at (rx (* (syntax whitespace))
- (group "/") "*"))
- (goto-char (match-beginning 1))
- (move-marker start-marker (point))
- (replace-match " " nil nil nil 1))
- ;; Include whitespaces before /*.
- (goto-char start)
- (beginning-of-line)
- (setq start (point))
- ;; Mask spaces before "*/" if it is attached at the end
- ;; of a sentence rather than on its own line.
- (goto-char end)
- (when (looking-back (rx (not (syntax whitespace))
- (group (+ (syntax whitespace)))
- "*/")
- (line-beginning-position))
- (goto-char (match-beginning 1))
- (setq end-marker (point-marker))
- (setq end-len (- (match-end 1) (match-beginning 1)))
- (replace-match (make-string end-len ?x)
- nil nil nil 1))
- ;; If "*/" is on its own line, don't included it in the
- ;; filling region.
- (when (not end-marker)
- (goto-char end)
- (when (looking-back (rx "*/") 2)
- (backward-char 2)
- (skip-syntax-backward "-")
- (setq end (point))))
- ;; Let `fill-paragraph' do its thing.
- (goto-char orig-point)
- (narrow-to-region start end)
- ;; We don't want to fill the region between START and
- ;; START-MARKER, otherwise the filling function might delete
- ;; some spaces there.
- (fill-region start-marker end arg)
- ;; Unmask.
- (when start-marker
- (goto-char start-marker)
- (delete-char 1)
- (insert "/"))
- (when end-marker
- (goto-char end-marker)
- (delete-region (point) (+ end-len (point)))
- (insert (make-string end-len ?\s))))))
-
-(defun c-ts-mode-comment-setup ()
- "Set up local variables for C-like comment.
-
-Set up:
- - `comment-start'
- - `comment-end'
- - `comment-start-skip'
- - `comment-end-skip'
- - `adaptive-fill-mode'
- - `adaptive-fill-first-line-regexp'
- - `paragraph-start'
- - `paragraph-separate'
- - `fill-paragraph-function'"
- (setq-local comment-start "// ")
- (setq-local comment-end "")
- (setq-local comment-start-skip (rx (or (seq "/" (+ "/"))
- (seq "/" (+ "*")))
- (* (syntax whitespace))))
- (setq-local comment-end-skip
- (rx (* (syntax whitespace))
- (group (or (syntax comment-end)
- (seq (+ "*") "/")))))
- (setq-local adaptive-fill-mode t)
- ;; This matches (1) empty spaces (the default), (2) "//", (3) "*",
- ;; but do not match "/*", because we don't want to use "/*" as
- ;; prefix when filling. (Actually, it doesn't matter, because
- ;; `comment-start-skip' matches "/*" which will cause
- ;; `fill-context-prefix' to use "/*" as a prefix for filling, that's
- ;; why we mask the "/*" in `c-ts-mode--fill-paragraph'.)
- (setq-local adaptive-fill-regexp
- (concat (rx (* (syntax whitespace))
- (group (or (seq "/" (+ "/")) (* "*"))))
- adaptive-fill-regexp))
- ;; Note the missing * comparing to `adaptive-fill-regexp'. The
- ;; reason for its absence is a bit convoluted to explain. Suffice
- ;; to say that without it, filling a single line paragraph that
- ;; starts with /* doesn't insert * at the beginning of each
- ;; following line, and filling a multi-line paragraph whose first
- ;; two lines start with * does insert * at the beginning of each
- ;; following line. If you know how does adaptive filling works, you
- ;; know what I mean.
- (setq-local adaptive-fill-first-line-regexp
- (rx bos
- (seq (* (syntax whitespace))
- (group (seq "/" (+ "/")))
- (* (syntax whitespace)))
- eos))
- ;; Same as `adaptive-fill-regexp'.
- (setq-local paragraph-start
- (rx (or (seq (* (syntax whitespace))
- (group (or (seq "/" (+ "/")) (* "*")))
- (* (syntax whitespace))
- ;; Add this eol so that in
- ;; `fill-context-prefix', `paragraph-start'
- ;; doesn't match the prefix.
- eol)
- "\f")))
- (setq-local paragraph-separate paragraph-start)
- (setq-local fill-paragraph-function #'c-ts-mode--fill-paragraph))
-
;;; Modes
(defvar-keymap c-ts-mode-map
@@ -968,7 +756,7 @@ c-ts-base-mode
(setq-local indent-tabs-mode t))
;; Comment
- (c-ts-mode-comment-setup)
+ (c-ts-common-comment-setup)
;; Electric
(setq-local electric-indent-chars
diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index 04f7f22236..852e893dc2 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -34,7 +34,7 @@
(require 'cc-mode)
(require 'cc-langs)
(require 'treesit)
-(require 'c-ts-mode) ; For comment indenting and filling.
+(require 'c-ts-common) ; For comment indenting and filling.
(eval-when-compile
(require 'cc-fonts)
@@ -634,8 +634,8 @@ csharp-ts-mode--indent-rules
((node-is "}") parent-bol 0)
((node-is ")") parent-bol 0)
((node-is "]") parent-bol 0)
- ((and (parent-is "comment") c-ts-mode--looking-at-star)
- c-ts-mode--comment-start-after-first-star -1)
+ ((and (parent-is "comment") c-ts-common-looking-at-star)
+ c-ts-common-comment-start-after-first-star -1)
((parent-is "comment") prev-adaptive-prefix 0)
((parent-is "namespace_declaration") parent-bol 0)
((parent-is "class_declaration") parent-bol 0)
@@ -908,7 +908,7 @@ csharp-ts-mode
(treesit-parser-create 'c-sharp)
;; Comments.
- (c-ts-mode-comment-setup)
+ (c-ts-common-comment-setup)
;; Indent.
(setq-local treesit-simple-indent-rules csharp-ts-mode--indent-rules)
diff --git a/lisp/progmodes/java-ts-mode.el b/lisp/progmodes/java-ts-mode.el
index 8251d9603c..af2b0c1fa8 100644
--- a/lisp/progmodes/java-ts-mode.el
+++ b/lisp/progmodes/java-ts-mode.el
@@ -29,7 +29,7 @@
(require 'treesit)
(eval-when-compile (require 'rx))
-(require 'c-ts-mode) ; For comment indent and filling.
+(require 'c-ts-common) ; For comment indent and filling.
(declare-function treesit-parser-create "treesit.c")
(declare-function treesit-induce-sparse-tree "treesit.c")
@@ -73,8 +73,8 @@ java-ts-mode--indent-rules
((node-is "}") (and parent parent-bol) 0)
((node-is ")") parent-bol 0)
((node-is "]") parent-bol 0)
- ((and (parent-is "comment") c-ts-mode--looking-at-star)
- c-ts-mode--comment-start-after-first-star -1)
+ ((and (parent-is "comment") c-ts-common-looking-at-star)
+ c-ts-common-comment-start-after-first-star -1)
((parent-is "comment") prev-adaptive-prefix 0)
((parent-is "text_block") no-indent)
((parent-is "class_body") parent-bol java-ts-mode-indent-offset)
@@ -293,7 +293,7 @@ java-ts-mode
(treesit-parser-create 'java)
;; Comments.
- (c-ts-mode-comment-setup)
+ (c-ts-common-comment-setup)
;; Indent.
(setq-local treesit-simple-indent-rules java-ts-mode--indent-rules)
diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
index 176024863f..b5c912b8b0 100644
--- a/lisp/progmodes/js.el
+++ b/lisp/progmodes/js.el
@@ -54,7 +54,7 @@
(require 'json)
(require 'prog-mode)
(require 'treesit)
-(require 'c-ts-mode) ; For comment indent and filling.
+(require 'c-ts-common) ; For comment indent and filling.
(eval-when-compile
(require 'cl-lib)
@@ -3428,8 +3428,8 @@ js--treesit-indent-rules
((node-is ")") parent-bol 0)
((node-is "]") parent-bol 0)
((node-is ">") parent-bol 0)
- ((and (parent-is "comment") c-ts-mode--looking-at-star)
- c-ts-mode--comment-start-after-first-star -1)
+ ((and (parent-is "comment") c-ts-common-looking-at-star)
+ c-ts-common-comment-start-after-first-star -1)
((parent-is "comment") prev-adaptive-prefix 0)
((parent-is "ternary_expression") parent-bol js-indent-level)
((parent-is "member_expression") parent-bol js-indent-level)
@@ -3806,7 +3806,7 @@ js-ts-mode
;; Which-func.
(setq-local which-func-imenu-joiner-function #'js--which-func-joiner)
;; Comment.
- (c-ts-mode-comment-setup)
+ (c-ts-common-comment-setup)
(setq-local comment-multi-line t)
;; Electric-indent.
(setq-local electric-indent-chars
diff --git a/lisp/progmodes/rust-ts-mode.el b/lisp/progmodes/rust-ts-mode.el
index 08590ae6a8..3a6cb61b71 100644
--- a/lisp/progmodes/rust-ts-mode.el
+++ b/lisp/progmodes/rust-ts-mode.el
@@ -29,7 +29,7 @@
(require 'treesit)
(eval-when-compile (require 'rx))
-(require 'c-ts-mode) ; For comment indent and filling.
+(require 'c-ts-common) ; For comment indent and filling.
(declare-function treesit-parser-create "treesit.c")
(declare-function treesit-induce-sparse-tree "treesit.c")
@@ -71,8 +71,8 @@ rust-ts-mode--indent-rules
((node-is ")") parent-bol 0)
((node-is "]") parent-bol 0)
((node-is "}") (and parent parent-bol) 0)
- ((and (parent-is "comment") c-ts-mode--looking-at-star)
- c-ts-mode--comment-start-after-first-star -1)
+ ((and (parent-is "comment") c-ts-common-looking-at-star)
+ c-ts-common-comment-start-after-first-star -1)
((parent-is "comment") prev-adaptive-prefix 0)
((parent-is "arguments") parent-bol rust-ts-mode-indent-offset)
((parent-is "await_expression") parent-bol rust-ts-mode-indent-offset)
@@ -285,7 +285,7 @@ rust-ts-mode
(treesit-parser-create 'rust)
;; Comments.
- (c-ts-mode-comment-setup)
+ (c-ts-common-comment-setup)
;; Font-lock.
(setq-local treesit-font-lock-settings rust-ts-mode--font-lock-settings)
diff --git a/lisp/progmodes/typescript-ts-mode.el b/lisp/progmodes/typescript-ts-mode.el
index 903be93422..3403096880 100644
--- a/lisp/progmodes/typescript-ts-mode.el
+++ b/lisp/progmodes/typescript-ts-mode.el
@@ -30,7 +30,7 @@
(require 'treesit)
(require 'js)
(eval-when-compile (require 'rx))
-(require 'c-ts-mode) ; For comment indent and filling.
+(require 'c-ts-common) ; For comment indent and filling.
(declare-function treesit-parser-create "treesit.c")
@@ -74,8 +74,8 @@ typescript-ts-mode--indent-rules
((node-is ")") parent-bol 0)
((node-is "]") parent-bol 0)
((node-is ">") parent-bol 0)
- ((and (parent-is "comment") c-ts-mode--looking-at-star)
- c-ts-mode--comment-start-after-first-star -1)
+ ((and (parent-is "comment") c-ts-common-looking-at-star)
+ c-ts-common-comment-start-after-first-star -1)
((parent-is "comment") prev-adaptive-prefix 0)
((parent-is "ternary_expression") parent-bol typescript-ts-mode-indent-offset)
((parent-is "member_expression") parent-bol typescript-ts-mode-indent-offset)
@@ -321,7 +321,7 @@ typescript-ts-base-mode
:syntax-table typescript-ts-mode--syntax-table
;; Comments.
- (c-ts-mode-comment-setup)
+ (c-ts-common-comment-setup)
;; Electric
(setq-local electric-indent-chars
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-21 12:24 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-01-21 12:38 ` Eli Zaretskii
2023-01-21 12:46 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2023-01-21 12:38 UTC (permalink / raw)
To: Theodor Thornhill; +Cc: casouri, rpluim, 60961
> From: Theodor Thornhill <theo@thornhill.no>
> Cc: rpluim@gmail.com, 60961@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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings
2023-01-21 12:38 ` Eli Zaretskii
@ 2023-01-21 12:46 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 14+ messages in thread
From: Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-21 12:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: casouri, rpluim, 60961
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: rpluim@gmail.com, 60961@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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-01-21 12:46 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-20 10:30 bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings Robert Pluim
2023-01-20 13:36 ` Eli Zaretskii
2023-01-20 13:50 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-20 14:15 ` Eli Zaretskii
2023-01-20 14:43 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-20 15:17 ` Eli Zaretskii
2023-01-20 16:07 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-20 22:11 ` Yuan Fu
2023-01-20 22:30 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-20 22:36 ` Yuan Fu
2023-01-21 4:18 ` Eli Zaretskii
2023-01-21 12:24 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-21 12:38 ` Eli Zaretskii
2023-01-21 12:46 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).