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#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file Date: Mon, 21 Nov 2022 14:41:11 +0200 Message-ID: <83cz9g4h08.fsf@gnu.org> References: <83v8n94ij9.fsf@gnu.org> <87k03pwgf6.fsf@thornhill.no> <83h6yt4c12.fsf@gnu.org> <87v8n9qscd.fsf@thornhill.no> <87pmdhqqni.fsf@thornhill.no> <87tu2tthmr.fsf@thornhill.no> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31806"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, 59415@debbugs.gnu.org To: Theodor Thornhill Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 21 13:42:28 2022 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 1ox684-00081o-79 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Nov 2022 13:42:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ox67h-0004mS-Aj; Mon, 21 Nov 2022 07:42:05 -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 1ox67e-0004kC-TS for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 07:42:03 -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 1ox67e-0002Vi-G9 for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 07:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ox67d-0005ZB-T0 for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 07:42: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: Mon, 21 Nov 2022 12:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59415 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: casouri@gmail.com, bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.166903446821332 (code B ref -1); Mon, 21 Nov 2022 12:42:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 21 Nov 2022 12:41:08 +0000 Original-Received: from localhost ([127.0.0.1]:45688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox66m-0005Xz-Am for submit@debbugs.gnu.org; Mon, 21 Nov 2022 07:41:08 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:34696) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox66i-0005Xq-Ld for submit@debbugs.gnu.org; Mon, 21 Nov 2022 07:41:06 -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 1ox66g-0003wZ-83 for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 07:41:03 -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 1ox66f-0002Oo-PG; Mon, 21 Nov 2022 07:41:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=gNbuO29Ds1+m9K/Vv61QsNWe8+9K/d1+AIttxbn8B6c=; b=ql3fSZw3nnBkqDcmXjhV X2D2Se5ImEvqBHiO3tVaQcFqJFIq3ickArWl0M2BA1U7lrOLEVQPkWWI981mcwyoiGn+aXDyFDCcm L0Sk16ImmV6SkG1Wf3mIhuzRt38NcCGiR6RhiDZeZJERFX/nG4EKIySN4nyF+G7pGyJbj9lYfdIIT oxtptkMBZNhyLd+vzmU643Pss7Q2bHeFo1kh+lcyGsbP+P2RjAfBaaEGW+cdoY/pjPU4V/YOXQwO8 slhx/jivhEdS+l0+QdCkoxtdxi/3tT8z971RmkXrKkJCh3AG04GtKSxwGk3rHu+iWRpLtrRSQsGJ7 /6SiY9mCXTa61w==; 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 1ox66e-0001Lx-UJ; Mon, 21 Nov 2022 07:41:01 -0500 In-Reply-To: <87tu2tthmr.fsf@thornhill.no> (message from Theodor Thornhill on Sun, 20 Nov 2022 22:56:12 +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:248520 Archived-At: > From: Theodor Thornhill > Cc: Eli Zaretskii , Bug Report Emacs > Date: Sun, 20 Nov 2022 22:56:12 +0100 > > > I tried the "top-level node” approach, and it didn’t help in > > package-rrc.c: the top-level node (a function definition) is still too > > large (spans 7680306-9936062). Since the case I described in the > > comment against using treesit-node-on is the exception rather than the > > norm, maybe we can go the other way around: use treesit-node-on first, > > and if the node seems too small (by some heuristic), enlarge it to > > some degree. > > > > Makes sense! > > BTW, should the chunk-size of jit-lock be up for discussion again? I > ran the benchmarks from this thread [0] on this file, and it seems like > increasing the chunk-size from 1500 to 4500 by 500 increments makes it > average from 2 seconds to 1.65. > > The density of that file absolutely is a concern performance-wise. FWIW, if the root cause is the humongous data structure, I'm not too worried, because such cases are extremely rare. If some clever idea arises that could improve things without endangering more practical use cases, then fine; otherwise, I'm okay with the slightly slower performance in these extreme cases -- after all, the interactive responsiveness is not that bad. But I still don't understand why fontifications stopped _completely_ starting at that line. That is, if the entire strict is in error, why most of it is fontified, and only the last party isn't? what is the mechanism which causes that? Thanks.