unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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).