* 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).