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

Previous Next

Full log

View this message in rfc822 format

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

Eli Zaretskii <eliz <at> gnu.org> writes:

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

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

Theo

Previous Next

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