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#64818: 30.0.50; c++-ts-mode highlight does not work Date: Mon, 24 Jul 2023 19:56:05 +0300 Message-ID: <83pm4hqme2.fsf@gnu.org> References: <83sf9dsewi.fsf@gnu.org> <87ila9sann.fsf@thornhill.no> <834jlts9q0.fsf@gnu.org> <87pm4h5qk2.fsf@thornhill.no> <83wmypqokz.fsf@gnu.org> <9173CE5D-08AE-4BF3-AD37-3B521845F8AC@thornhill.no> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23978"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64818@debbugs.gnu.org, dianchengwang@gmail.com To: Theodor Thornhill , casouri@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 24 18:56:36 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 1qNyrL-00061v-Sm for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 24 Jul 2023 18:56:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNyqt-0007Vk-0C; Mon, 24 Jul 2023 12:56:07 -0400 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 1qNyqp-0006zT-Tb for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 12:56:04 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qNyqo-0007aJ-IQ for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 12:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNyqn-0005Td-WF for bug-gnu-emacs@gnu.org; Mon, 24 Jul 2023 12:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Jul 2023 16:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64818 X-GNU-PR-Package: emacs Original-Received: via spool by 64818-submit@debbugs.gnu.org id=B64818.169021773621019 (code B ref 64818); Mon, 24 Jul 2023 16:56:01 +0000 Original-Received: (at 64818) by debbugs.gnu.org; 24 Jul 2023 16:55:36 +0000 Original-Received: from localhost ([127.0.0.1]:43901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNyqO-0005Sw-7G for submit@debbugs.gnu.org; Mon, 24 Jul 2023 12:55:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNyqJ-0005SV-UG for 64818@debbugs.gnu.org; Mon, 24 Jul 2023 12:55:32 -0400 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 1qNyqD-0007Hx-K2; Mon, 24 Jul 2023 12:55:25 -0400 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=3knfkNorZx0ZXOt2LwvLGe9qrkK/9reLxjH7uKwPFYY=; b=hq3QcEuDlLD1 fuvVeJw9Inj3jLMu8r1KhfuFxC++MYRgRx+OdpuXjs1GgKKjP/pTYhVviWEKvZbx7Xfth4CqwHLMA j91Gb2tK1c7OMRCTsnplRLjxM+iQLfQCkA8BE0yXVuM41kTnKYGKVjpfIjd5swNDSLco/NeuymuLk NvtdcSYrvqJKpig/5wHm6Tvgp+RXzzRlDM0iYgFcjwt7IGxh3cnb7BMNCjjB+1B3jzRFV4hsdOGqO nkqIAi/OdN/UPdgIJ7bnx7ppP/OYb+UApgJl0+xyp7PybE7WhIpABDMFmzFVg7mOV7ujpVEWU3Asc eeE4wwzxC/yYYf2aw+rf3A==; 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 1qNyqB-0006vK-1H; Mon, 24 Jul 2023 12:55:23 -0400 In-Reply-To: <9173CE5D-08AE-4BF3-AD37-3B521845F8AC@thornhill.no> (message from Theodor Thornhill on Mon, 24 Jul 2023 18:40:44 +0200) 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:265986 Archived-At: > Date: Mon, 24 Jul 2023 18:40:44 +0200 > From: Theodor Thornhill > > >> Yep, nullptr was changed from named node to unnamed node last week [0]. > >> > >> I think we can live without a compat change and only target the node > >> as a normal keyword. I'll commit the fix if it is simple enough (the > >> simplest is just to remove the node altogether), > >> otherwise I'll send a patch for review. Sounds ok? > > > >I'd prefer to see the patch. Also, can you tell more about the effect > >of the change you propose ("remove the node")? > > > > In this case it will only make the symbol "nullptr" get no font locking. That's probably good enough. And CC Mode doesn't fontify it, either. Can you show the patch? > >More generally, I'm a bit worried by such incompatible changes in the > >grammar libraries. The developers must understand that they break > >users of tree-sitter, right? So why are they making such incompatible > >changes? And how do other editors cope with such changes, for example > >this one? > > An example from nvim-treesitter: https://github.com/nvim-treesitter/nvim-treesitter/commit/823e67a1c9452075ec7f01e7aa05ac6e7b41fb1e > > It seems most, if not all implementations use some sort of lockfile, where commits are frozen according to the current support. The consensus seems to be to do what I proposed some mails ago: show the last known commit the current file supports, and enable that one to be installed automatically. I'm not sure how we would maintain this data. Emacs is a large project, and people come and go at will and without further notice. We don't have people who will reliably track the development of the grammar libraries and record the commits somewhere. We'd basically need this when a release is being tarred, and for that it should be recorded somewhere in advance. > >I'm asking these questions because perhaps we are doing something we > >shouldn't, or not doing something we should. I don't think we can > >tell our users to use only a specific commit from the grammar > >libraries' repositories: a significant portion of Emacs users tend to > >switch to a new version many moons after the release (e.g., I see > >reports from people who only now upgrade from Emacs 27 to Emacs 28, > >more than a year since Emacs 28 was released). So a grammar library > >which was the current one on the release date will be hopelessly > >outdated by the time some users will switch to that Emacs version. > > > >So we must look for some more robust way, if it exists. > > I agree, but I'm not sure what that looks like. What about catching errors inside treesit.c or treesit.el, so that the features that disappeared and queries that fail don't fail the entire font-lock? Would that work, or at least make Emacs more robust in the face of such changes? Yuan, WDYT? (This more robust approach is certainly not for Emacs 29.1, even if we agree that it's a good idea.)