From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#60961: 29.0.60; Compiling emacs-29 without treesitter outputs warnings Date: Fri, 20 Jan 2023 16:15:57 +0200 Message-ID: <83tu0lmgv6.fsf@gnu.org> References: <878rhx1os6.fsf@gmail.com> <831qnpnx9g.fsf@gnu.org> <87o7qtuxgh.fsf@thornhill.no> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14220"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rpluim@gmail.com, casouri@gmail.com, 60961@debbugs.gnu.org To: Theodor Thornhill Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 20 15:17:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pIsCq-0003VP-D9 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 Jan 2023 15:17:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIsCa-0005RL-3R; Fri, 20 Jan 2023 09:17:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIsCX-0005Qu-Jz for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2023 09:17:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pIsCU-0005AV-92 for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2023 09:17:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pIsCT-0001Tw-TG for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2023 09:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Jan 2023 14:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60961 X-GNU-PR-Package: emacs Original-Received: via spool by 60961-submit@debbugs.gnu.org id=B60961.16742241765618 (code B ref 60961); Fri, 20 Jan 2023 14:17:01 +0000 Original-Received: (at 60961) by debbugs.gnu.org; 20 Jan 2023 14:16:16 +0000 Original-Received: from localhost ([127.0.0.1]:45976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pIsBj-0001SY-Rd for submit@debbugs.gnu.org; Fri, 20 Jan 2023 09:16:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pIsBi-0001SJ-LE for 60961@debbugs.gnu.org; Fri, 20 Jan 2023 09:16:15 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIsBd-00054e-4i; Fri, 20 Jan 2023 09:16:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tmTMrJudkoOSU/P+wDfrpuSHLyG+OYBZJZ2AIC7G6jo=; b=b+6LlN5kn9AC hUjZ8/zitKeo37uFbQIyvRFpsNhFCH4byST4RZpFnjwOddPocLTBm4riKl2Vv/TD1f7hTph6PGseK PyJp1SPYvRQr+0oItVnlqx9tAsXN+RC8Mr4ThDXifC8R+fklsh6ieM2f8xRGZY4TLFg6vxBj18Fhr WeHQl5yS+hW1CF0ywPpExNZ86edI/pR+2zYJCuKM8J+QCu6n2sduu5MAqo+PwAfAATeRy9JZMSTNI oSw/7h4d7xswX2iE5paxWZsSXwul71vlFxV5xXa1VIgIyzEEvw5iIOUqU1RRqFi7Y0UQRZXDs7pxs OzcBVAvLxqjBaCqJCaILDQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIsBR-0001H4-Ql; Fri, 20 Jan 2023 09:16:08 -0500 In-Reply-To: <87o7qtuxgh.fsf@thornhill.no> (message from Theodor Thornhill on Fri, 20 Jan 2023 14:50:22 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:253778 Archived-At: > From: Theodor Thornhill > Cc: 60961@debbugs.gnu.org > Date: Fri, 20 Jan 2023 14:50:22 +0100 > > Eli Zaretskii 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?