From unknown Sat Jun 21 10:34:47 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#59415 <59415@debbugs.gnu.org> To: bug#59415 <59415@debbugs.gnu.org> Subject: Status: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file Reply-To: bug#59415 <59415@debbugs.gnu.org> Date: Sat, 21 Jun 2025 17:34:47 +0000 retitle 59415 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a p= ortion of a large C file reassign 59415 emacs submitter 59415 Eli Zaretskii severity 59415 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 12:55:58 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 17:55:58 +0000 Received: from localhost ([127.0.0.1]:44513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owoXu-0003L2-3T for submit@debbugs.gnu.org; Sun, 20 Nov 2022 12:55:58 -0500 Received: from lists.gnu.org ([209.51.188.17]:55492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owoXq-0003Kr-JQ for submit@debbugs.gnu.org; Sun, 20 Nov 2022 12:55:56 -0500 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 1owoXq-0002Ce-4X for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 12:55:54 -0500 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 1owoXo-00064w-3I; Sun, 20 Nov 2022 12:55:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=yL4MAASUZWwAtUel8CCx+T0bmr2fmBjnb4zjcG1XFtI=; b=gMnfOowPKm4Y6P MgQCIo49XBsV+LCcRlhxyhBctyIetHiDbrP3UMtAOmC5sNIll2sgJcYyq131wX2vcxPVTH8RXG/89 pA47VLSGfZqCAKKKHlpOyl6sIihIdLphH3kMOzKrfeMn5WyxxJkbGGqqVpSTmJQI4fvMTpvDCU8jS A/SC7QmaFQboLrTFxhE254pHl/GrMVzxQSdYxN9pwuwtYM9U7XzsRZrpL63Iic0mOFHVecIgjRPEw d/RU/Lmg0fHiQCA2FLUQuGYvGXZxsGD8NTLBX4+FlgBX0LAuj4EowpWx7pBwxv8nYK/EcX+b4SGBF hPSOdzS7f9yLVksr+vOg==; 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 1owoXg-0002rF-UG; Sun, 20 Nov 2022 12:55:51 -0500 Date: Sun, 20 Nov 2022 19:55:54 +0200 Message-Id: <83v8n94ij9.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: Yuan Fu , Theodor Thornhill X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) To reproduce: emacs -Q Evaluate: (setq auto-mode-alist (append '(("\\.c\\'" . c-ts-mode)) auto-mode-alist)) (setq treesit-max-buffer-size (* 11 1024 1024)) C-x C-f packet-rrc.c RET (This file is the one from bug#45248.) C-u 194770 M-g g Observe that fontifications stop at this line for some reason. Fontification reappears on line 209271. Maybe it's because of the many braces that appear in warning face? Why does TS think there are syntax errors here? The C++ TS parser doesn't have that problem, btw. P.S. Btw, isn't the treesit-max-buffer-size limit too low? 4 MiB? In GNU Emacs 29.0.50 (build 31, i686-pc-mingw32) of 2022-11-20 built on HOME-C4E4A596F7 Repository revision: 4fa13b2d838e11cbe3b713f3172721cb61d499f3 Repository branch: feature/tree-sitter Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: C Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils c-ts-mode rx treesit cl-seq vc-bzr vc-dispatcher vc-cvs vc-rcs log-view easy-mmode pcvs-util cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 71496 109093) (symbols 48 8917 42) (strings 16 25650 9189) (string-bytes 1 810278) (vectors 16 13855) (vector-slots 8 190997 54271) (floats 8 26 158) (intervals 40 583 684) (buffers 904 13)) From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 14:54:27 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 19:54:27 +0000 Received: from localhost ([127.0.0.1]:44702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owqOY-0000Cv-M0 for submit@debbugs.gnu.org; Sun, 20 Nov 2022 14:54:27 -0500 Received: from lists.gnu.org ([209.51.188.17]:38164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owqOS-0000Ch-Aa for submit@debbugs.gnu.org; Sun, 20 Nov 2022 14:54:24 -0500 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 1owqOS-0001dU-4z for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 14:54:20 -0500 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owqOP-00014s-4y; Sun, 20 Nov 2022 14:54:19 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1668974052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kLQijqgzTCmgqU/aX9VJuKHb+Vg1Cr4eZtGdpdTg2xs=; b=kUkc49LG/Xk45lTCwkGQH2dGg5MPcRm4rpl/AgOXMxoJGjOigRqCFix6xVEiGeiszfTa0G 4dNnjgZF2r+NzHkMFT74bIH1TVq3nBl41ECa9j5LUqVmWyBwwuxzW7MWqrRPVyYc6jhT7k LsM0kT3w6I+XfuL3dz3YibCrtydA6YRWvJFNcEnwouARIpiqhMvOrjkx2EoNImrADFHqUl T4hM3cHve3pqLkfYiC9ADnevFyy2/FEMkfj4oWxdWDNFFqGYmlLaBtanFxKCiM6L60pxtJ mFX+ho6gAXFktQmp55yD5CKyYYkddtcsJM9VUqBMgDAL/oD51OFhtJ3rdlLjmQ== From: Theodor Thornhill To: Eli Zaretskii , bug-gnu-emacs@gnu.org Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file In-Reply-To: <83v8n94ij9.fsf@gnu.org> References: <83v8n94ij9.fsf@gnu.org> Date: Sun, 20 Nov 2022 20:54:05 +0100 Message-ID: <87k03pwgf6.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=2001:41d0:2:aacc::; envelope-from=theo@thornhill.no; helo=out2.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hi and thanks for cc. > > Observe that fontifications stop at this line for some reason. > Fontification reappears on line 209271. Maybe it's because of the many > braces that appear in warning face? Why does TS think there are syntax > errors here? The C++ TS parser doesn't have that problem, btw. > It seems the c parser definitely can't handle what it's seeing. > P.S. Btw, isn't the treesit-max-buffer-size limit too low? 4 MiB? > It might be! IIRC treesit uses 10x the buffer size to store the ast, so it'll be some more memory usage. I'll do some more digging, but in the meantime I attach this profiler report that shows font-locking as the culprit: In this profile I followed your repro, and did some more movement around the buffer after. This isn't from emacs -Q, but I believe the results will be just the same, considering where the slowness seems to be 16695 85% - redisplay_internal (C function) 16695 85% - jit-lock-function 16695 85% - jit-lock-fontify-now 16695 85% - jit-lock--run-functions 16695 85% - run-hook-wrapped 16695 85% - # 16695 85% - font-lock-fontify-region 16695 85% - font-lock-default-fontify-region 16679 84% - treesit-font-lock-fontify-region 2080 10% treesit-buffer-root-node 2689 13% - command-execute 2689 13% - call-interactively 2380 12% - funcall-interactively 1576 8% - scroll-up-command 1525 7% - scroll-up 1525 7% - jit-lock-function 1525 7% - jit-lock-fontify-now 1525 7% - jit-lock--run-functions 1525 7% - run-hook-wrapped 1525 7% - # 1525 7% - font-lock-fontify-region 1525 7% - font-lock-default-fontify-region 1525 7% treesit-font-lock-fontify-region 633 3% - end-of-buffer 628 3% - recenter 628 3% - jit-lock-function 628 3% - jit-lock-fontify-now 628 3% - jit-lock--run-functions 628 3% - run-hook-wrapped 628 3% - # 628 3% - font-lock-fontify-region 628 3% - font-lock-default-fontify-region 628 3% treesit-font-lock-fontify-region 5 0% push-mark 128 0% - project-find-file 128 0% - project-find-file-in 86 0% - project--read-file-cpd-relative 86 0% - project--completing-read-strict 86 0% - completing-read 86 0% - completing-read-default 86 0% - apply 86 0% - vertico--advice 86 0% - apply 86 0% - # 79 0% - read-from-minibuffer 37 0% - vertico--exhibit 26 0% - vertico--update 22 0% redisplay 4 0% - vertico--recompute 4 0% - vertico-sort-history-length-alpha 4 0% - mapcan 4 0% - # 4 0% sort 11 0% - vertico--display-candidates 11 0% vertico--resize-window 15 0% - timer-event-handler 10 0% - apply 7 0% - battery-update-handler 7 0% - sit-for 7 0% - redisplay 7 0% redisplay_internal (C function) 3 0% # 2 0% - internal-timer-start-idle 2 0% timerp 2 0% - command-execute 2 0% - call-interactively 2 0% - funcall-interactively 2 0% - vertico-exit 2 0% - vertico--match-p 2 0% - test-completion 2 0% - # 2 0% complete-with-action 27 0% - find-file 27 0% - find-file-noselect 24 0% - find-file-noselect-1 4 0% - insert-file-contents 4 0% - set-auto-coding 4 0% - find-auto-coding 4 0% sgml-html-meta-auto-coding-function 4 0% - after-find-file 4 0% - normal-mode 4 0% - set-auto-mode 4 0% - set-auto-mode--apply-alist 4 0% - set-auto-mode-0 4 0% - c-ts-mode 4 0% treesit-ready-p 3 0% - find-buffer-visiting 3 0% abbreviate-file-name 15 0% - project-files 15 0% - apply 15 0% - # 15 0% - mapcan 15 0% - # 15 0% - project--vc-list-files 11 0% - apply 11 0% - vc-git--run-command-string 11 0% - # 11 0% - kill-buffer 11 0% - replace-buffer-in-windows 11 0% - unrecord-window-buffer 11 0% assq-delete-all 4 0% split-string 5 0% - next-line 5 0% - line-move 5 0% line-move-visual 4 0% - execute-extended-command 4 0% - command-execute 4 0% - call-interactively 4 0% - funcall-interactively 4 0% profiler-stop 2 0% - digit-argument 2 0% - universal-argument--mode 2 0% set-transient-map 309 1% - byte-code 309 1% - read-extended-command 309 1% - read-extended-command-1 309 1% - completing-read 309 1% - completing-read-default 309 1% - apply 309 1% - vertico--advice 309 1% - apply 309 1% - # 276 1% - read-from-minibuffer 253 1% - vertico--exhibit 249 1% - vertico--update 240 1% - vertico--recompute 236 1% - vertico--all-completions 236 1% - apply 236 1% - completion-all-completions 236 1% - completion--nth-completion 236 1% - completion--some 236 1% - # 163 0% - completion-basic-all-completions 163 0% - completion-pcm--all-completions 163 0% - all-completions 163 0% - # 163 0% - complete-with-action 4 0% - all-completions 4 0% - # 4 0% # 73 0% - completion-substring-all-completions 73 0% - completion-substring--all-completions 64 0% - completion-pcm--all-completions 64 0% - all-completions 64 0% - # 64 0% complete-with-action 4 0% - test-completion 4 0% - # 4 0% complete-with-action 7 0% redisplay 4 0% - vertico--display-candidates 4 0% vertico--resize-window 4 0% - redisplay_internal (C function) 4 0% - eval 4 0% unless 201 1% + timer-event-handler 50 0% + ... 4 0% set-message-functions From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 15:16:23 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 20:16:23 +0000 Received: from localhost ([127.0.0.1]:44722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owqjm-0000ja-Lk for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:16:23 -0500 Received: from lists.gnu.org ([209.51.188.17]:53240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owqjk-0000jT-H5 for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:16:21 -0500 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 1owqjj-0006Xr-Hq for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 15:16:20 -0500 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 1owqji-0006OT-Lw; Sun, 20 Nov 2022 15:16:18 -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=BzZ9ZqRV/HEsyrb61lfHo3vtfZAGp8jBeRaH/Mzpt0Y=; b=GeCnRoxKExnN GVzfFq6fD2bw0FBNOZrKkH5TUp8piN8gB9t+M7CYazpUVXyaobq0hjGS+FIamwKbtzsmmatCGHkCX TLNMbVXOGJv5osz1P0p1c+NG7hNTqcGEJ1fAkMKcafM50zGLfCgOh1qbWsXVWRcXeo/MmB9TKsqsg kjF+LMb1jBH2OjhbMAMfEnfw7lRjxz6hfkGIpMiX6XOl7R6t5l3URjY3QGjuu6XnpyG+iJkDGalyV 2XYfpovtoxbiGcf69spXCONOuchA75BWcqYz3Ks3ZGOZSn41br7cJA9Ffy+c+IeaV+8vd47IqG5Wl XWiox2jvnULQCEmG0OTC3A==; 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 1owqjh-0005t8-LI; Sun, 20 Nov 2022 15:16:18 -0500 Date: Sun, 20 Nov 2022 22:16:25 +0200 Message-Id: <83h6yt4c12.fsf@gnu.org> From: Eli Zaretskii To: Theodor Thornhill In-Reply-To: <87k03pwgf6.fsf@thornhill.no> (message from Theodor Thornhill on Sun, 20 Nov 2022 20:54:05 +0100) Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file References: <83v8n94ij9.fsf@gnu.org> <87k03pwgf6.fsf@thornhill.no> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Theodor Thornhill > Cc: Yuan Fu > Date: Sun, 20 Nov 2022 20:54:05 +0100 > > > Observe that fontifications stop at this line for some reason. > > Fontification reappears on line 209271. Maybe it's because of the many > > braces that appear in warning face? Why does TS think there are syntax > > errors here? The C++ TS parser doesn't have that problem, btw. > > It seems the c parser definitely can't handle what it's seeing. Yes, but do you have any clue why it gives up at that line? One thing that I see is that many braces around there are shown in warning face, so perhaps the parser is overwhelmed by the amount of parsing errors? > > P.S. Btw, isn't the treesit-max-buffer-size limit too low? 4 MiB? > > It might be! IIRC treesit uses 10x the buffer size to store the ast, so > it'll be some more memory usage. After lifting the limit to allow visiting the file, this file causes Emacs to go up to 350 MiB. Which is significant, but definitely not outrageous enough to prevent using TS with this file. And I'm sure "normal" C files (as opposed to ones written by a program) will need less memory. So 4 MiB sounds too restrictive to me. We should maybe increase that to 15 MiB on 32-bit systems and say 40 MiB on 64-bit? > I'll do some more digging, but in the > meantime I attach this profiler report that shows font-locking as the > culprit: Culprit for what? For slow performance? Don't get me wrong: from my POV, TS works here better than CC Mode, in many use cases which are much more important than scrolling through the entire humongous file top to bottom. For example, just visiting the file takes 3 times as much with CC Mode as with c-ts-mode; going to EOB with CC Mode takes more 1 min 20 sec, whereas TS does it in 2.5 sec. And likewise jumping into a random point in the file. Instead of Alan's 150 sec for a full scroll by CC Mode I get 27 min. The number of GC cycles with CC Mode is 10 times as large as with TS. (Caveat: my Emacs is built without optimizations, whereas Tree-sitter and the language support libraries are, of course, fully optimized.) > In this profile I followed your repro, and did some more movement around > the buffer after. This isn't from emacs -Q, but I believe the results > will be just the same, considering where the slowness seems to be > > > 16695 85% - redisplay_internal (C function) > 16695 85% - jit-lock-function > 16695 85% - jit-lock-fontify-now > 16695 85% - jit-lock--run-functions > 16695 85% - run-hook-wrapped > 16695 85% - # > 16695 85% - font-lock-fontify-region > 16695 85% - font-lock-default-fontify-region > 16679 84% - treesit-font-lock-fontify-region Yes, treesit-font-lock-fontify-region takes the lion's share. If you or Yuan can speed this up, please do. But I see no reason to consider this a catastrophe, quite to the contrary. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 15:17:37 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 20:17:37 +0000 Received: from localhost ([127.0.0.1]:44733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owqky-0000lo-PM for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:17:37 -0500 Received: from lists.gnu.org ([209.51.188.17]:46812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owqkx-0000lg-ET for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:17:35 -0500 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 1owqkx-0006qh-A1 for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 15:17:35 -0500 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owqku-0006V4-Qb; Sun, 20 Nov 2022 15:17:35 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1668975448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QUYvKiQogoi24tqcQRxXO2euezYRAEXotaYPgURnXKo=; b=Bkg2qCOXrY8bRTEM/Q6dCpCs78hzo7neimk9ueaSiSx5CmJyDWpbgEWBdZrqILOdfpjbjS WP1wmOtqfvKfKInLu+buG0apvjOwwY92YdH+b15E+Sgm/Gv9FL7sWJrazsXGwbYHWfRlKh 6oORIYVhsHztomQilXdFYHE7uIOEFihHbFNxhbJx6BfzVOahYKrsbrlGFmAJWguU1MiALN 3hs88/5vhpF3QIk2hW1MmShpPiUjLLJAiLqv3tgLqEPFfc9DRFFcfp8Y0BU/sU5992XCVj 8ivyQNMKGw2yUzivXYUAj/Z5kDf5SW8WYTiflIKeRoOaejaRdWr2rPu9g1y9cw== From: Theodor Thornhill To: Eli Zaretskii , bug-gnu-emacs@gnu.org Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file In-Reply-To: <83v8n94ij9.fsf@gnu.org> References: <83v8n94ij9.fsf@gnu.org> Date: Sun, 20 Nov 2022 21:17:20 +0100 Message-ID: <87y1s5qt2n.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=2001:41d0:2:aacc::; envelope-from=theo@thornhill.no; helo=out2.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) > > P.S. Btw, isn't the treesit-max-buffer-size limit too low? 4 MiB? I thought it was supposed to be 4 gigs, as seen in this function: ``` static void treesit_check_buffer_size (struct buffer *buffer) { ptrdiff_t buffer_size = (BUF_Z (buffer) - BUF_BEG (buffer)); if (buffer_size > UINT32_MAX) xsignal2 (Qtreesit_buffer_too_large, build_pure_c_string ("Buffer size cannot be larger than 4GB"), make_fixnum (buffer_size)); } ``` So my guess is that that is a typo, and should be (defcustom treesit-max-buffer-size (* 4 1024 1024 1024) "Maximum buffer size for enabling tree-sitter parsing (in bytes)." :type 'integer :version "29.1") or something like that :-) Theo From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 15:33:22 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 20:33:22 +0000 Received: from localhost ([127.0.0.1]:44739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owr0E-00019j-9N for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:33:22 -0500 Received: from lists.gnu.org ([209.51.188.17]:59734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owr0C-00019b-Dh for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:33:21 -0500 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 1owr0C-0001LJ-8N for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 15:33:20 -0500 Received: from out0.migadu.com ([2001:41d0:2:267::]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owr09-0000LT-98; Sun, 20 Nov 2022 15:33:19 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1668976394; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uKdpTeYZ+o5peTl/XEnSCrQ26Agtw4Xg/S3pEnS8Nkg=; b=r9NUyVHpLG2DI+vdoACBM20Ez2raBccXl1GrAbcLItkfjGVvZ8c1Pj0HkhLE7dIZpMQcmV BIryXsAFSmpFJMuGxd+2sfaGP0cOTUGy9aMm149zmroqalZzEmITypcTE6TgKP5uKMV2oB DU4pSk6W2CQHFa1xI+3mKdpUsgslw8YV41sfUJXgbm5+JN7Dg6L92FwfeTp65VS8/QFVMV Rxb+KPM1/kKyX6xTt7cChxMbYxh2M35ybH8MJqv0RhS0XXMyEr8VCbjKV1lHbzE7rnccrn 4gBfLQEYPm16HIiu+sS9x92y7/9JchQhzaXRKZhTCTVHXE/ARjDVmlPgs3svxg== From: Theodor Thornhill To: Eli Zaretskii Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file In-Reply-To: <83h6yt4c12.fsf@gnu.org> References: <83v8n94ij9.fsf@gnu.org> <87k03pwgf6.fsf@thornhill.no> <83h6yt4c12.fsf@gnu.org> Date: Sun, 20 Nov 2022 21:33:06 +0100 Message-ID: <87v8n9qscd.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=2001:41d0:2:267::; envelope-from=theo@thornhill.no; helo=out0.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Eli Zaretskii writes: >> From: Theodor Thornhill >> Cc: Yuan Fu >> Date: Sun, 20 Nov 2022 20:54:05 +0100 >> >> > Observe that fontifications stop at this line for some reason. >> > Fontification reappears on line 209271. Maybe it's because of the many >> > braces that appear in warning face? Why does TS think there are syntax >> > errors here? The C++ TS parser doesn't have that problem, btw. >> >> It seems the c parser definitely can't handle what it's seeing. > > Yes, but do you have any clue why it gives up at that line? > No, not yet. > One thing that I see is that many braces around there are shown in warning > face, so perhaps the parser is overwhelmed by the amount of parsing errors? > Yeah that's my first guess, but that shouldn't be an issue, it should be able to font-lock _something_. >> > P.S. Btw, isn't the treesit-max-buffer-size limit too low? 4 MiB? >> >> It might be! IIRC treesit uses 10x the buffer size to store the ast, so >> it'll be some more memory usage. > > After lifting the limit to allow visiting the file, this file causes Emacs > to go up to 350 MiB. Which is significant, but definitely not outrageous > enough to prevent using TS with this file. And I'm sure "normal" C files > (as opposed to ones written by a program) will need less memory. So 4 MiB > sounds too restrictive to me. We should maybe increase that to 15 MiB on > 32-bit systems and say 40 MiB on 64-bit? > I think it should probably be the same as in the C level, as I mentioned in the other mail? >> I'll do some more digging, but in the >> meantime I attach this profiler report that shows font-locking as the >> culprit: > > Culprit for what? For slow performance? Yeah. > Don't get me wrong: from my POV, TS works here better than CC Mode, in > many use cases which are much more important than scrolling through > the entire humongous file top to bottom. For example, just visiting > the file takes 3 times as much with CC Mode as with c-ts-mode; going > to EOB with CC Mode takes more 1 min 20 sec, whereas TS does it in 2.5 > sec. And likewise jumping into a random point in the file. Instead > of Alan's 150 sec for a full scroll by CC Mode I get 27 min. The > number of GC cycles with CC Mode is 10 times as large as with TS. > (Caveat: my Emacs is built without optimizations, whereas Tree-sitter > and the language support libraries are, of course, fully optimized.) > Ok, that's good to know! >> In this profile I followed your repro, and did some more movement around >> the buffer after. This isn't from emacs -Q, but I believe the results >> will be just the same, considering where the slowness seems to be >> >> >> 16695 85% - redisplay_internal (C function) >> 16695 85% - jit-lock-function >> 16695 85% - jit-lock-fontify-now >> 16695 85% - jit-lock--run-functions >> 16695 85% - run-hook-wrapped >> 16695 85% - # >> 16695 85% - font-lock-fontify-region >> 16695 85% - font-lock-default-fontify-region >> 16679 84% - treesit-font-lock-fontify-region > > Yes, treesit-font-lock-fontify-region takes the lion's share. If you or > Yuan can speed this up, please do. But I see no reason to consider this a > catastrophe, quite to the contrary. I think it boils down to getting the root too many times. In an unmodified buffer I think getting the root node should be instant, and it seems to take some time. I'll try to figure out why. Theo From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 15:52:09 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 20:52:09 +0000 Received: from localhost ([127.0.0.1]:44755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owrIP-0001dd-9d for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:52:09 -0500 Received: from lists.gnu.org ([209.51.188.17]:35730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owrIK-0001dR-07 for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:52:07 -0500 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 1owrIJ-0004vk-QW for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 15:52:03 -0500 Received: from out0.migadu.com ([94.23.1.103]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owrIH-0003df-R3; Sun, 20 Nov 2022 15:52:03 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1668977519; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1woLPWJraeyMiji+09c25Wu4LwPuz/tm63g39P4lYZE=; b=wyG0Hz2CW9OuXa4/sHaAdgbeMWB5lSxi8oblpz/fukebNSYJ85eRBoDmdywZby2iXN4r5n xCgUHOSIRg1AIqYuHdy9frNJSmtO/EUMnwFaW544rvPUaUO/o2Rgwj2LFzqS6FFs1dqcX8 CPSAPpZ8qOeGNmrxC386TaBtdODmhr1HDzIs8epMF7z5d601zpVRBNZdOd5XgzsvIwCi0L lSA9dTay0xKao0FN2xEH47htqrqW49JLaKr4plc+dPmpeifchaFKUdRlZfsRMNYqQ0nfsE 2QffNeusjwz9Tp1vFvIV/Bx+ixnaJkgDGFWJ9wkmwRPj2jNIBzBZTof0J65cDA== From: Theodor Thornhill To: Eli Zaretskii Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file In-Reply-To: <87v8n9qscd.fsf@thornhill.no> References: <83v8n94ij9.fsf@gnu.org> <87k03pwgf6.fsf@thornhill.no> <83h6yt4c12.fsf@gnu.org> <87v8n9qscd.fsf@thornhill.no> Date: Sun, 20 Nov 2022 21:51:51 +0100 Message-ID: <87sfidqrh4.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=94.23.1.103; envelope-from=theo@thornhill.no; helo=out0.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org, casouri@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Theodor Thornhill writes: > Eli Zaretskii writes: > >>> From: Theodor Thornhill >>> Cc: Yuan Fu >>> Date: Sun, 20 Nov 2022 20:54:05 +0100 >>> >>> > Observe that fontifications stop at this line for some reason. >>> > Fontification reappears on line 209271. Maybe it's because of the many >>> > braces that appear in warning face? Why does TS think there are syntax >>> > errors here? The C++ TS parser doesn't have that problem, btw. >>> >>> It seems the c parser definitely can't handle what it's seeing. >> >> Yes, but do you have any clue why it gives up at that line? >> > > No, not yet. > > This diff fixes the font-lock issues: diff --git a/lisp/treesit.el b/lisp/treesit.el index 674c984dfe..0f84d8b83e 100644 --- a/lisp/treesit.el +++ b/lisp/treesit.el @@ -774,12 +774,12 @@ treesit-font-lock-fontify-region ;; will give you that quote node. We want to capture the string ;; and apply string face to it, but querying on the quote node ;; will not give us the string node. - (when-let ((root (treesit-buffer-root-node language)) + (when-let ( ;; Only activate if ENABLE flag is t. (activate (eq t enable))) (ignore activate) (let ((captures (treesit-query-capture - root query start end)) + (treesit-node-on start end) query start end)) (inhibit-point-motion-hooks t)) (with-silent-modifications (dolist (capture captures) However, the comment right above makes a case for why we should have this. BUT, is this still relevant, Yuan, after the changes in treesit reporting what has changed etc? What exact case is that an issue? And is it more severe than the behavior this bug is exhibiting? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 15:59:51 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 20:59:51 +0000 Received: from localhost ([127.0.0.1]:44759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owrPr-0001o1-7l for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:59:51 -0500 Received: from lists.gnu.org ([209.51.188.17]:43284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owrPo-0001ns-2u for submit@debbugs.gnu.org; Sun, 20 Nov 2022 15:59:50 -0500 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 1owrPn-0006dB-Tb for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 15:59:47 -0500 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1owrPl-0004qz-WF; Sun, 20 Nov 2022 15:59:47 -0500 Received: by mail-pg1-x531.google.com with SMTP id f3so9502572pgc.2; Sun, 20 Nov 2022 12:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xoZViityy/fvF3K79xYrX1DL/IMApUMtmCvLhVbP024=; b=gXDrp6/yTcYRMKBUS/fXpCvGPA4IxDl9gqFK1hPmjhdrM0xYYeOpNGl1ViP3wgi9dE dAJWVKSp7mUYiQ/+Ssqqceh+LQ4kjfttittZMkbIxV9cYheZ38wkepQbQbQRFJARFKeO G6PHT+mU76OalUpC49wC4pWvr0UNsQ9PIYJnusBMPus3mSEhMlI1UpK+wyaGCD/3tMRu vMAp5PJmW4nrUd+9HbkJ54Bu96os80Mo+c3rJddKVVGWldz3KMkPYEVzcjDGsxA3N3s+ kWbIjc1wOeWXOZSSryCWR8DC5LXIRWi+mE36MdBTX3I1h/z6jVd2B6E47UsAzAHEA8bp 4D9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xoZViityy/fvF3K79xYrX1DL/IMApUMtmCvLhVbP024=; b=xfNq+C+mRxWXc2R3UbxDHSTabWNkYBPjxVfRJ1Jfnz6nSNscn7JPszH5WE7MVhXU81 uUi3wPiKj/cIw/MJP2nkUi2WouKgJvS7vWLDsMTKqLRaLouMJs2LfZoI9RPPLc53tM09 NP0avBmkigm3POQS9evNNE+YdJo6zdiiUtnqSc0aAjIIAFa/OilTVF8p3HDGCNWeknFc UP/VLL9kO1F443ONAxQ/7Ob9LbOAk9E9tzOlWRV4dHmgJh+dwxhv6YGtDeFJfMOXtSG7 JQtPn1tvV2DNn3TPX3l2+OFku3tJ/adu5F+gJyvDD6ek7ju2f5DLAPUTTnZV1yKlKPtD NlFw== X-Gm-Message-State: ANoB5plCYTCSWVw9ijwgL8t47Q6AydXcJ/eDSGXhdq0FA5rfIziaxmTb i5zKQcfHUQ1PqvIIuCMWO98= X-Google-Smtp-Source: AA0mqf5pitLNyhl60Hs6SE94ODhAyIFTNmzNCRykgHDxvUVPdEHzPOdH9Scav1Mp0BDTilIFWvdRrw== X-Received: by 2002:a63:2160:0:b0:46f:f26e:e8ba with SMTP id s32-20020a632160000000b0046ff26ee8bamr15512017pgm.250.1668977984002; Sun, 20 Nov 2022 12:59:44 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id fh18-20020a17090b035200b00218a4795b0dsm1920057pjb.34.2022.11.20.12.59.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2022 12:59:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file From: Yuan Fu In-Reply-To: <87v8n9qscd.fsf@thornhill.no> Date: Sun, 20 Nov 2022 12:59:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83v8n94ij9.fsf@gnu.org> <87k03pwgf6.fsf@thornhill.no> <83h6yt4c12.fsf@gnu.org> <87v8n9qscd.fsf@thornhill.no> To: Theodor Thornhill X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::531; envelope-from=casouri@gmail.com; helo=mail-pg1-x531.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , Bug Report Emacs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > On Nov 20, 2022, at 12:33 PM, Theodor Thornhill = wrote: >=20 > Eli Zaretskii writes: >=20 >>> From: Theodor Thornhill >>> Cc: Yuan Fu >>> Date: Sun, 20 Nov 2022 20:54:05 +0100 >>>=20 >>>> Observe that fontifications stop at this line for some reason. >>>> Fontification reappears on line 209271. Maybe it's because of the = many >>>> braces that appear in warning face? Why does TS think there are = syntax >>>> errors here? The C++ TS parser doesn't have that problem, btw. >>>=20 >>> It seems the c parser definitely can't handle what it's seeing. >>=20 >> Yes, but do you have any clue why it gives up at that line? >>=20 >=20 > No, not yet. Because the whole thing is contained in an ERROR node. I wasn=E2=80=99t = covered in error face because our rule for error doesn=E2=80=99t = =E2=80=9Coverride=E2=80=9D: if there are existing faces in the range, = the error face isn=E2=80=99t applied. If I change the rule fontifying = errors to override, everything is in error face. Alternatively, if you = disable fontifying errors, like this: (add-hook 'c-ts-mode-hook #'c-ts-setup) (defun c-ts-setup () (treesit-font-lock-recompute-features nil '(error))) >=20 >=20 >> One thing that I see is that many braces around there are shown in = warning >> face, so perhaps the parser is overwhelmed by the amount of parsing = errors? >>=20 >=20 > Yeah that's my first guess, but that shouldn't be an issue, it should = be > able to font-lock _something_. Yeah, see above. >=20 >>>> P.S. Btw, isn't the treesit-max-buffer-size limit too low? 4 MiB? >>>=20 >>> It might be! IIRC treesit uses 10x the buffer size to store the = ast, so >>> it'll be some more memory usage. >>=20 >> After lifting the limit to allow visiting the file, this file causes = Emacs >> to go up to 350 MiB. Which is significant, but definitely not = outrageous >> enough to prevent using TS with this file. And I'm sure "normal" C = files >> (as opposed to ones written by a program) will need less memory. So = 4 MiB >> sounds too restrictive to me. We should maybe increase that to 15 = MiB on >> 32-bit systems and say 40 MiB on 64-bit? >>=20 >=20 > I think it should probably be the same as in the C level, as I = mentioned > in the other mail? 4GB is the absolute upper limit, but the practical maximum size if well = below that. Thought 4MB might be too conservative. >=20 >>> I'll do some more digging, but in the >>> meantime I attach this profiler report that shows font-locking as = the >>> culprit: >>=20 >> Culprit for what? For slow performance? >=20 > Yeah. >=20 >> Don't get me wrong: from my POV, TS works here better than CC Mode, = in >> many use cases which are much more important than scrolling through >> the entire humongous file top to bottom. For example, just visiting >> the file takes 3 times as much with CC Mode as with c-ts-mode; going >> to EOB with CC Mode takes more 1 min 20 sec, whereas TS does it in = 2.5 >> sec. And likewise jumping into a random point in the file. Instead >> of Alan's 150 sec for a full scroll by CC Mode I get 27 min. The >> number of GC cycles with CC Mode is 10 times as large as with TS. >> (Caveat: my Emacs is built without optimizations, whereas Tree-sitter >> and the language support libraries are, of course, fully optimized.) >>=20 >=20 > Ok, that's good to know! >=20 >>> In this profile I followed your repro, and did some more movement = around >>> the buffer after. This isn't from emacs -Q, but I believe the = results >>> will be just the same, considering where the slowness seems to be >>>=20 >>>=20 >>> 16695 85% - redisplay_internal (C function) >>> 16695 85% - jit-lock-function >>> 16695 85% - jit-lock-fontify-now >>> 16695 85% - jit-lock--run-functions >>> 16695 85% - run-hook-wrapped >>> 16695 85% - # >>> 16695 85% - font-lock-fontify-region >>> 16695 85% - font-lock-default-fontify-region >>> 16679 84% - treesit-font-lock-fontify-region >>=20 >> Yes, treesit-font-lock-fontify-region takes the lion's share. If you = or >> Yuan can speed this up, please do. But I see no reason to consider = this a >> catastrophe, quite to the contrary. >=20 > I think it boils down to getting the root too many times. In an > unmodified buffer I think getting the root node should be instant, and > it seems to take some time. I'll try to figure out why. Getting root is trivial, the bulk of the time is spent in query-capture Running the following in that file gives me 1.87 seconds, while in a = smaller file it only takes 0.00016. (benchmark-run 100 (let ((query (caar treesit-font-lock-settings)) (root (treesit-buffer-root-node))) (treesit-query-capture root query 7700472 7703604))) > This diff fixes the font-lock issues: >=20 > diff --git a/lisp/treesit.el b/lisp/treesit.el > index 674c984dfe..0f84d8b83e 100644 > --- a/lisp/treesit.el > +++ b/lisp/treesit.el > @@ -774,12 +774,12 @@ treesit-font-lock-fontify-region > ;; will give you that quote node. We want to capture the string > ;; and apply string face to it, but querying on the quote node > ;; will not give us the string node. > - (when-let ((root (treesit-buffer-root-node language)) > + (when-let ( > ;; Only activate if ENABLE flag is t. > (activate (eq t enable))) > (ignore activate) > (let ((captures (treesit-query-capture > - root query start end)) > + (treesit-node-on start end) query start = end)) > (inhibit-point-motion-hooks t)) > (with-silent-modifications > (dolist (capture captures) >=20 >=20 > However, the comment right above makes a case for why we should have > this. BUT, is this still relevant, Yuan, after the changes in treesit > reporting what has changed etc? What exact case is that an issue? = And > is it more severe than the behavior this bug is exhibiting? The case described by the comment is still relevant. With this patch, = the quote described in that case still wouldn=E2=80=99t be fontified. We = can use some heuristic to get a node =E2=80=9Clarge enough=E2=80=9D and = not the root node. Eg, find some top-level node. That should make = query-capture much faster. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 16:09:53 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 21:09:53 +0000 Received: from localhost ([127.0.0.1]:44764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owrZY-00023F-ON for submit@debbugs.gnu.org; Sun, 20 Nov 2022 16:09:53 -0500 Received: from lists.gnu.org ([209.51.188.17]:47384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owrZW-000237-D7 for submit@debbugs.gnu.org; Sun, 20 Nov 2022 16:09:50 -0500 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 1owrZV-00081q-ME for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 16:09:49 -0500 Received: from out2.migadu.com ([188.165.223.204]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owrZT-0006Zr-6d; Sun, 20 Nov 2022 16:09:49 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1668978584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MMJz15Q46Dwcg5BMSVIat+bcYe1rc7e2nkt8FZeRwcs=; b=aW3uEFF2LvFPDApk3xu07UhxGEtJm9zHVS3q9PVyqu+4QtE0e8rpbV6+w76aWjFQW/dfju 6zm6d7zAFrUIQiBnLas5QPJSh2xet37M5cK+avjxb5Pf41u96EB8B0XOHKxbm3qMjZKzTn UF1MwsmC9leZmy3Kb++96V3WB5iy8YbHGIAwQKgZOV6HwuKXT1gqfn4wERDznCjGECqmkt 2fh2A/5lsworrgLMRS5RYGx6/2Mj7RTngM51hJYtp541G8NL/TwaCQ+ocrcwd/bPuBq27R 5C+6UIPJIHlXBQitKBpmw3hhfgSSczrv3dxj4425u/sY24sW5TfKa/viQ4G6zw== From: Theodor Thornhill To: Yuan Fu Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file In-Reply-To: References: <83v8n94ij9.fsf@gnu.org> <87k03pwgf6.fsf@thornhill.no> <83h6yt4c12.fsf@gnu.org> <87v8n9qscd.fsf@thornhill.no> Date: Sun, 20 Nov 2022 22:09:37 +0100 Message-ID: <87pmdhqqni.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=188.165.223.204; envelope-from=theo@thornhill.no; helo=out2.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , Bug Report Emacs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) >> This diff fixes the font-lock issues: >>=20 >> diff --git a/lisp/treesit.el b/lisp/treesit.el >> index 674c984dfe..0f84d8b83e 100644 >> --- a/lisp/treesit.el >> +++ b/lisp/treesit.el >> @@ -774,12 +774,12 @@ treesit-font-lock-fontify-region >> ;; will give you that quote node. We want to capture the string >> ;; and apply string face to it, but querying on the quote node >> ;; will not give us the string node. >> - (when-let ((root (treesit-buffer-root-node language)) >> + (when-let ( >> ;; Only activate if ENABLE flag is t. >> (activate (eq t enable))) >> (ignore activate) >> (let ((captures (treesit-query-capture >> - root query start end)) >> + (treesit-node-on start end) query start end)) >> (inhibit-point-motion-hooks t)) >> (with-silent-modifications >> (dolist (capture captures) >>=20 >>=20 >> However, the comment right above makes a case for why we should have >> this. BUT, is this still relevant, Yuan, after the changes in treesit >> reporting what has changed etc? What exact case is that an issue? And >> is it more severe than the behavior this bug is exhibiting? > > The case described by the comment is still relevant. With this patch, > the quote described in that case still wouldn=E2=80=99t be fontified. We = can > use some heuristic to get a node =E2=80=9Clarge enough=E2=80=9D and not t= he root > node. Eg, find some top-level node. That should make query-capture > much faster. > I appreciate the explanation. I think getting the root is a bit excessive. I got the same results as you in the capture. Maybe reuse the treesit-defun-type-regexp, and default to root if none found? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 16:27:13 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 21:27:13 +0000 Received: from localhost ([127.0.0.1]:44773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owrqK-0002SL-RZ for submit@debbugs.gnu.org; Sun, 20 Nov 2022 16:27:13 -0500 Received: from lists.gnu.org ([209.51.188.17]:59204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owrqH-0002SC-R5 for submit@debbugs.gnu.org; Sun, 20 Nov 2022 16:27:12 -0500 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 1owrqH-00029D-Lh for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 16:27:09 -0500 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1owrqG-0003SY-0h; Sun, 20 Nov 2022 16:27:09 -0500 Received: by mail-pj1-x102e.google.com with SMTP id v3-20020a17090ac90300b00218441ac0f6so11843310pjt.0; Sun, 20 Nov 2022 13:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ko52a8Pv0sPC0ckS+htv8lxAFZwkMBwOJE8X+I9oJAo=; b=coXZJWWD49y0lxJkBW9ItqWxfI9ATlRAhwtA7UsXQY1viTrlfIgJlOCGKvqaGOMn2y 7I4QydO8FxsaqyAZKz56scPO4hlpSPjioHZwf5p3Cq+ht1bMjMj3hsj4g9zvT9qNyOKb EdUjxCRvB6QdHfQqhtNs+h0JmOAH79ac+09FQxdw5h8BL6jJPPxt6qQM/0P9NaFi8j1P t9f6VJzazLFP491kpPU9u1Z4eGxnOwCE8sFRWWuzz5IPeRHDAQvfrKHGNzz7dz3nDnya pI4ugL9aBUjBJiTfnBfqiXgwje8adFN6V+rAYgKoyiUPXEfQAkTCgt9fpUIzez5qlgAn WvFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ko52a8Pv0sPC0ckS+htv8lxAFZwkMBwOJE8X+I9oJAo=; b=3riX6THPSEZ5fTaM3hqksWHGcxD2df4s6LEYFzu1/m00laY2i33DtyyzkMTVX2KvGu MEz+uF+VWBRLEXKhXSe6eLM//AuRQKj6YSH7bgWzhkBZed+wZgGzjJKvl3G2oqZPcDw1 zzKLkQ7qcjA6GT1RYkjU3DzFZU9t9lR0ovJMjIGnAPVNkgc9RL/XctUFnqPeg6y3Ein7 qudi1vXe+9ISfLrvDrEDEUTmrWTlhFh4RLLH18Aybe54SoAfAPpWQRxiJKgpZSwinNZy DjstQ/hEQCSADMAPfM4v6uDih8I8HBH5tJJv851N92sT80K50kLUioeVCfzvPpdEb9Di yebA== X-Gm-Message-State: ANoB5pnqi4j0hdfOXSx8k79C84aBJssEgvB+Ili5H/i/EGhe9AWupnGU 5qp0XH/5N31yM/uufzECjPg5CRHv/oc= X-Google-Smtp-Source: AA0mqf66kSVHp+230l97CecUvceaLF9iw9v/A0QlnOUNPVrs53YV78lLgyy4OQNW4AD7PcAz+9ps9g== X-Received: by 2002:a17:90a:4049:b0:210:5de0:f3e3 with SMTP id k9-20020a17090a404900b002105de0f3e3mr17291438pjg.61.1668979626017; Sun, 20 Nov 2022 13:27:06 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id x15-20020aa7940f000000b0056bfd4a2702sm7075842pfo.45.2022.11.20.13.27.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2022 13:27:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file From: Yuan Fu In-Reply-To: <87pmdhqqni.fsf@thornhill.no> Date: Sun, 20 Nov 2022 13:27:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83v8n94ij9.fsf@gnu.org> <87k03pwgf6.fsf@thornhill.no> <83h6yt4c12.fsf@gnu.org> <87v8n9qscd.fsf@thornhill.no> <87pmdhqqni.fsf@thornhill.no> To: Theodor Thornhill X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::102e; envelope-from=casouri@gmail.com; helo=mail-pj1-x102e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , Bug Report Emacs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > On Nov 20, 2022, at 1:09 PM, Theodor Thornhill = wrote: >=20 >>> This diff fixes the font-lock issues: >>>=20 >>> diff --git a/lisp/treesit.el b/lisp/treesit.el >>> index 674c984dfe..0f84d8b83e 100644 >>> --- a/lisp/treesit.el >>> +++ b/lisp/treesit.el >>> @@ -774,12 +774,12 @@ treesit-font-lock-fontify-region >>> ;; will give you that quote node. We want to capture the = string >>> ;; and apply string face to it, but querying on the quote node >>> ;; will not give us the string node. >>> - (when-let ((root (treesit-buffer-root-node language)) >>> + (when-let ( >>> ;; Only activate if ENABLE flag is t. >>> (activate (eq t enable))) >>> (ignore activate) >>> (let ((captures (treesit-query-capture >>> - root query start end)) >>> + (treesit-node-on start end) query start = end)) >>> (inhibit-point-motion-hooks t)) >>> (with-silent-modifications >>> (dolist (capture captures) >>>=20 >>>=20 >>> However, the comment right above makes a case for why we should have >>> this. BUT, is this still relevant, Yuan, after the changes in = treesit >>> reporting what has changed etc? What exact case is that an issue? = And >>> is it more severe than the behavior this bug is exhibiting? >>=20 >> The case described by the comment is still relevant. With this patch, >> the quote described in that case still wouldn=E2=80=99t be fontified. = We can >> use some heuristic to get a node =E2=80=9Clarge enough=E2=80=9D and = not the root >> node. Eg, find some top-level node. That should make query-capture >> much faster. >>=20 >=20 > I appreciate the explanation. I think getting the root is a bit > excessive. I got the same results as you in the capture. Maybe reuse > the treesit-defun-type-regexp, and default to root if none found? I tried the "top-level node=E2=80=9D approach, and it didn=E2=80=99t = 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. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 16:56:28 2022 Received: (at submit) by debbugs.gnu.org; 20 Nov 2022 21:56:28 +0000 Received: from localhost ([127.0.0.1]:44810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owsId-0003E8-QQ for submit@debbugs.gnu.org; Sun, 20 Nov 2022 16:56:28 -0500 Received: from lists.gnu.org ([209.51.188.17]:51920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owsIc-0003E0-28 for submit@debbugs.gnu.org; Sun, 20 Nov 2022 16:56:27 -0500 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 1owsIb-0007gB-E7 for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2022 16:56:25 -0500 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owsIZ-0000vs-DG; Sun, 20 Nov 2022 16:56:25 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1668981380; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JoIiS+VKopRMXz+AznSWQrxAbWttmlr4PfNMX8FI+T0=; b=zfgwYH53DiCZNUS1Nq8XNTIY4hB9FCjqotsy5cNVzhVSRBvf0I0LGYrOzf1VEs03EiUno9 zYPzNDBI6Gx1NGAHGoE1NBLU+Xytc7UKxwAvyU5RbaFYD3QxAup03hoQ6OR28eGbiARrYh SlfTA3PJ5qL0ms2DL16sWtA2bXcX942eRYBBsqIGSFnFb0Pqo9besMEPdGdTrPaEvzW7gf t6FmLPZ6pbugBzj4Uo8zgkTy9jFlEYVp4KeQ13OyAZCX6GKLI5ahMjM+83ucuLhtnPnZFK gKUcMGfJ1ieyfu/BYUdkiBw/Dgb8P9GiYvlcbVE/qXynAGF0rvVLTEDLIHArPg== From: Theodor Thornhill To: Yuan Fu Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file In-Reply-To: References: <83v8n94ij9.fsf@gnu.org> <87k03pwgf6.fsf@thornhill.no> <83h6yt4c12.fsf@gnu.org> <87v8n9qscd.fsf@thornhill.no> <87pmdhqqni.fsf@thornhill.no> Date: Sun, 20 Nov 2022 22:56:12 +0100 Message-ID: <87tu2tthmr.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=2001:41d0:2:aacc::; envelope-from=theo@thornhill.no; helo=out2.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , Bug Report Emacs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) >>=20 >> I appreciate the explanation. I think getting the root is a bit >> excessive. I got the same results as you in the capture. Maybe reuse >> the treesit-defun-type-regexp, and default to root if none found? > > I tried the "top-level node=E2=80=9D approach, and it didn=E2=80=99t 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. Theo [0]: https://lists.gnu.org/archive/html/emacs-devel/2021-09/msg00538.html From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 20 20:27:27 2022 Received: (at 59415) by debbugs.gnu.org; 21 Nov 2022 01:27:27 +0000 Received: from localhost ([127.0.0.1]:44952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owvao-0002H7-RN for submit@debbugs.gnu.org; Sun, 20 Nov 2022 20:27:27 -0500 Received: from mail-pj1-f47.google.com ([209.85.216.47]:53873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owvam-0002Gt-4Z for 59415@debbugs.gnu.org; Sun, 20 Nov 2022 20:27:25 -0500 Received: by mail-pj1-f47.google.com with SMTP id t17so8453720pjo.3 for <59415@debbugs.gnu.org>; Sun, 20 Nov 2022 17:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jDq0JYymJMT/MZsR/rcj+QncJQhH0i1TQUhPMp4KGSY=; b=QrH7lnsXE62WOW8Ho0rAxLWBOlaQlbhodgp3/eORotTDJVNUn6wKUn7BwHZ71xi/62 RDk4mCi/2RA+xZVzKnM0JZSEfkgYcsBnu+Ny6j6m85OCkDnNLPkON7s+gcyg2PyEOhgS dkLltbIFt6jpG/OPlwWErqmGclTEeMu/7Cb6DGlvEytsEXFYYy+HBw7yjuY0lr0zMQQS bYNafiGq40MFHsXQMqaSpITUXx/a6TZau7wIOqgZ2GBL/tmxWjvmkuB0jkifRShhgfcK n/YTp1sLo2VTehhwRaTlYcmaYzvymvzSBd17RxtXv9lLmcSYLOQJrcM0ccX5AQ0GwB9l 2tDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jDq0JYymJMT/MZsR/rcj+QncJQhH0i1TQUhPMp4KGSY=; b=bEca6gjLibfyQvo2+pQjqMKg3v8qWHAUhj4zqGXpUBdnXkvGC9CkjvhvGlgw/JY4Wn JTXVDI6asCA9DkF5GqRxNgsESPSvYeqI2Vj046znNlmQ2pB8DPPgu3H/uIMXlCA2kOmz VGqgtZea2OhiXhH/Rj7euBUwPrmk50J03G2uS1iHugfD4j9zwk6b8c1RKe9BrFEgEKrx UdQoGf+kTm9TbNNynZRpreN/ZfBXccc+JrJCtuAhMdKPFo35ioUUbNxDNX/nlV4d8/fM mX3o4XadqKlqBfHpzKq7m3vhjdNmljp/A5C3Oz+mqhgDR6G62I0wUvZXKPsSIKqAsIVx MnlA== X-Gm-Message-State: ANoB5plTUmTQmEB4eaqZHJAEvhWpzoC/Thu6ZdvA6mPx351FEZYIj7tx Cr8QJ0DsKd8fsVYatqRax1o= X-Google-Smtp-Source: AA0mqf5LoNkGHaElK5tDEN4SU5BcXkIjgrs2BTSKFu2biXbXNOwdc3jNXMGYDrfi8LA91kcfKY3nRw== X-Received: by 2002:a17:90a:ff84:b0:213:1e05:f992 with SMTP id hf4-20020a17090aff8400b002131e05f992mr24388845pjb.191.1668994038121; Sun, 20 Nov 2022 17:27:18 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id b12-20020a170903228c00b001811a197797sm8191742plh.194.2022.11.20.17.27.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2022 17:27:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file From: Yuan Fu In-Reply-To: <87tu2tthmr.fsf@thornhill.no> Date: Sun, 20 Nov 2022 17:27:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Theodor Thornhill X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 59415 Cc: Eli Zaretskii , 59415@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Nov 20, 2022, at 1:56 PM, Theodor Thornhill via Bug reports for GNU = Emacs, the Swiss army knife of text editors = wrote: >=20 >>>=20 >>> I appreciate the explanation. I think getting the root is a bit >>> excessive. I got the same results as you in the capture. Maybe = reuse >>> the treesit-defun-type-regexp, and default to root if none found? >>=20 >> I tried the "top-level node=E2=80=9D approach, and it didn=E2=80=99t = 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. >>=20 >=20 > Makes sense! I pushed a change that uses treesit-node-on. Now scrolling in most parts = of the buffer is pretty fast. Scrolling around 194770 is still laggy, = because the node we get from treesit-node-on is still too large. I tried = some heuristics but they didn=E2=80=99t work very well, IMO because = tree-sitter couldn=E2=80=99t parse that part of the code very well. The = code should observe a structure like {{}, {}, {}, {}, {}, =E2=80=A6} = where there are tens thousands of inner brackets, so ideally we only = need to grab the {}=E2=80=99s in the region we want to fontify. But = tree-sitter seems to understand it in some weird structure and we still = end up with very large nodes, which is far larger than the region we = want to fontify and is slow to query. I=E2=80=99ll try to improve it further in the future, but for now I = think it=E2=80=99s good enough (because in most cases fontification is = pretty fast). Also I think we should probably disable fontifying errors in C. C=E2=80=99= s macros just create too much errors. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 06:00:50 2022 Received: (at 59415) by debbugs.gnu.org; 21 Nov 2022 11:00:50 +0000 Received: from localhost ([127.0.0.1]:45546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox4Xh-0000hB-KO for submit@debbugs.gnu.org; Mon, 21 Nov 2022 06:00:49 -0500 Received: from out0.migadu.com ([94.23.1.103]:63997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox4Xf-0000h2-CM for 59415@debbugs.gnu.org; Mon, 21 Nov 2022 06:00:48 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1669028445; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mLmKOtaSx9Q8rfLSdruyl0e/5XtuV1qq6bxeZdciBjI=; b=D4a/TTIPcdiAontrvtzRPidXKoYRXOxw4WlT2MP0NFBhlQ4sU/RhTXsJ+zqD6m92YD1cdf 2/+q6wfOHk7FhhMyyn6Lp0sIg4I3ahmUJvRanMyctdoyrSkiK5vxAfK8OHuCabUJWmPyVx T3yIcGK96g9He1sjY6ob6ddIcNsd9JukCWtboawhMvR6pGQlto75xROKGifNg732OK4Kmx Yk0A7L9syNGBeVcecYMPYQXiGKfczhgkq867ZoxX0WOc7/AJ0xU1M8Cx84CUNmZjUvcbFV RXIhs37h0Nn8+sPXuHbfLUB5dLNCLrZxPQggV/p+gkpyHnfZR+3iA+uouaDBoQ== From: Theodor Thornhill To: Yuan Fu Subject: Re: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file In-Reply-To: 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> Date: Mon, 21 Nov 2022 12:00:37 +0100 Message-ID: <87fsec8td6.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 59415 Cc: Eli Zaretskii , 59415@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Yuan Fu writes: >> On Nov 20, 2022, at 1:56 PM, Theodor Thornhill via Bug reports for GNU E= macs, the Swiss army knife of text editors wrote: >>=20 >>>>=20 >>>> I appreciate the explanation. I think getting the root is a bit >>>> excessive. I got the same results as you in the capture. Maybe reuse >>>> the treesit-defun-type-regexp, and default to root if none found? >>>=20 >>> I tried the "top-level node=E2=80=9D approach, and it didn=E2=80=99t he= lp 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. >>>=20 >>=20 >> Makes sense! > > I pushed a change that uses treesit-node-on. Now scrolling in most > parts of the buffer is pretty fast. Scrolling around 194770 is still > laggy, because the node we get from treesit-node-on is still too > large. I tried some heuristics but they didn=E2=80=99t work very well, IMO > because tree-sitter couldn=E2=80=99t parse that part of the code very > well. The code should observe a structure like {{}, {}, {}, {}, {}, =E2= =80=A6} > where there are tens thousands of inner brackets, so ideally we only > need to grab the {}=E2=80=99s in the region we want to fontify. But > tree-sitter seems to understand it in some weird structure and we > still end up with very large nodes, which is far larger than the > region we want to fontify and is slow to query. > > I=E2=80=99ll try to improve it further in the future, but for now I think= it=E2=80=99s > good enough (because in most cases fontification is pretty fast). > > Also I think we should probably disable fontifying errors in C. C=E2=80= =99s > macros just create too much errors. Good job. I ran this in both c-ts-mode and c-mode on the same file: (defun scroll-up-benchmark () (interactive) (let ((oldgc gcs-done) (oldtime (float-time))) (condition-case nil (while t (scroll-up) (redisplay)) (error (message "GCs: %d Elapsed time: %f seconds" (- gcs-done oldgc) (- (float-time) oldtime)))))) c-ts-mode: GCs: 87 Elapsed time: 135.700742 seconds c-mode: GCs: 224 Elapsed time: 133.329396 seconds Font locking seems correct too. Theo From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 07:41:08 2022 Received: (at submit) by debbugs.gnu.org; 21 Nov 2022 12:41:08 +0000 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 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 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 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==; 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 Date: Mon, 21 Nov 2022 14:41:11 +0200 Message-Id: <83cz9g4h08.fsf@gnu.org> From: Eli Zaretskii To: Theodor Thornhill In-Reply-To: <87tu2tthmr.fsf@thornhill.no> (message from Theodor Thornhill on Sun, 20 Nov 2022 22:56:12 +0100) Subject: Re: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file 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 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: casouri@gmail.com, bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 08:44:34 2022 Received: (at 59415) by debbugs.gnu.org; 21 Nov 2022 13:44:34 +0000 Received: from localhost ([127.0.0.1]:45818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox769-0000yn-Oj for submit@debbugs.gnu.org; Mon, 21 Nov 2022 08:44:33 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox767-0000yU-17 for 59415@debbugs.gnu.org; Mon, 21 Nov 2022 08:44:32 -0500 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 1ox760-00015z-6G; Mon, 21 Nov 2022 08:44:24 -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=IYEcrSqVUHLHOnXPxsWfanmR6sWCgRHBS1AZU7XEmeI=; b=dedJ345SqgL4PgVtEVTM tVH8zafcZ9T5vVg8uxpc2vsbu25TA4Ii1cwY94N23iKgo8hbLq1aol7s95TIzzP7HgRT2aDntuPYP CxkABBU43I4FQbCmOWqC6qCPe62gKR7DaXzO6rGRMTFuD7Au7Zzg7jTQoYs22cO+bdq9Y3zqJcZa3 Fys+l4L/uYXt4zHC1ZUn2hAnZJkhpfrdWnwaMtvXlXff1LyemgzrXoSRv1X5e4O2U3S2AYCvZOek8 bQ6TV3A7VqNIoKhh3hmDkLBvvkIZLO9vrjLc7ov7bh9QMxnfbg8JKOgeupNWMCU4hQZUEwswEO508 uh/AbuPfGP/ROw==; 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 1ox75z-0003H7-HD; Mon, 21 Nov 2022 08:44:23 -0500 Date: Mon, 21 Nov 2022 15:44:34 +0200 Message-Id: <83y1s42zi5.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Sun, 20 Nov 2022 17:27:16 -0800) Subject: Re: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file 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 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59415 Cc: 59415@debbugs.gnu.org, theo@thornhill.no X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Sun, 20 Nov 2022 17:27:16 -0800 > Cc: Eli Zaretskii , > 59415@debbugs.gnu.org > > Also I think we should probably disable fontifying errors in C. C’s macros just create too much errors. Let's make it optional. I think at least I would like to see those errors. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 10:15:13 2022 Received: (at 59415) by debbugs.gnu.org; 21 Nov 2022 15:15:13 +0000 Received: from localhost ([127.0.0.1]:48495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox8Vs-0000jb-QM for submit@debbugs.gnu.org; Mon, 21 Nov 2022 10:15:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox8Vo-0000HH-Mx for 59415@debbugs.gnu.org; Mon, 21 Nov 2022 10:15:12 -0500 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 1ox8Vi-00041D-CA; Mon, 21 Nov 2022 10:15:02 -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=syghu6QVHimobXY6WWvMNVGE3wIlp5Lq1aReAlxvLSI=; b=GI2VR4JkSuv7tFY+/dsy 4fA6GQtW2DY9dceRmGFYWIw2k176//VauyWFhGpklgbn1YASkz1iiDaCe6npKG1OJnD0Q3mTgy+sS fOoOBsbjSjG9yLYjSpQ5i1sGSrQN8hlCIMiaEsVZFDMgn07QAidx6EtKyAeJzZACUog4QGXF/z8AS WJgfXwPdkSlzaolApMQniI76r6ImKfnXf8N3jeyX2oFtwSp77IFDwFq2ORt8ZulnelEno5HkYBMfK F9wHKcFHlGXDgqNW9Ele2UOEqkhYSZ6b0LQgvEQJTykc1flvZfho31wRvcwmhH2uo2TClpREsRQYu M8oKTm7lUdzotA==; 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 1ox8Vh-0005GE-NS; Mon, 21 Nov 2022 10:15:02 -0500 Date: Mon, 21 Nov 2022 17:15:13 +0200 Message-Id: <83k03o2vb2.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Sun, 20 Nov 2022 17:27:16 -0800) Subject: Re: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file 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 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59415 Cc: 59415@debbugs.gnu.org, theo@thornhill.no X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Sun, 20 Nov 2022 17:27:16 -0800 > Cc: Eli Zaretskii , > 59415@debbugs.gnu.org > > I pushed a change that uses treesit-node-on. Now scrolling in most parts of the buffer is pretty fast. Scrolling around 194770 is still laggy, because the node we get from treesit-node-on is still too large. I tried some heuristics but they didn’t work very well, IMO because tree-sitter couldn’t parse that part of the code very well. The code should observe a structure like {{}, {}, {}, {}, {}, …} where there are tens thousands of inner brackets, so ideally we only need to grab the {}’s in the region we want to fontify. But tree-sitter seems to understand it in some weird structure and we still end up with very large nodes, which is far larger than the region we want to fontify and is slow to query. > > I’ll try to improve it further in the future, but for now I think it’s good enough (because in most cases fontification is pretty fast). Agreed. Thanks, I think we can close the bug now. What do you think about enlarging treesit-max-buffer-size as I proposed up-thread? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 11:53:35 2022 Received: (at 59415) by debbugs.gnu.org; 21 Nov 2022 16:53:35 +0000 Received: from localhost ([127.0.0.1]:48634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxA34-0005NF-T1 for submit@debbugs.gnu.org; Mon, 21 Nov 2022 11:53:35 -0500 Received: from mail-pg1-f172.google.com ([209.85.215.172]:33318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxA32-0005Mt-2W for 59415@debbugs.gnu.org; Mon, 21 Nov 2022 11:53:32 -0500 Received: by mail-pg1-f172.google.com with SMTP id b62so11735559pgc.0 for <59415@debbugs.gnu.org>; Mon, 21 Nov 2022 08:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wpfpI9sEMExB2FpHiQVGvr2Sa8u+aQIaDKmeFmjYQfE=; b=NK/AGBzp6kAKJMtHlubR7RkVO4ybQsrtjcB9yuseRgeCjECO8A1HXOHGdrsUsFh3jv a2+pLG23GzOOe8Q3LD0Um7Nx1A7URmZ8OXWr7MLmpqeAqs2hRzfzAsAovmfXwA0dL/5X 7W54U2X3ehFmq4l1AQAIfwdPsDOA0suYp331DhwBplS60HtfCEmtXpBW/kz6Ee4Id1Ab d9z/yDuXxFtDf1Mk6MQFyNJ/QcjdCg3N7bEzfBkJdfXwIrqrOG34iDsmajmd1T3iOdfi Zg3s7+rMfP/8r3ZNHip4S8tyct7WbEoF3Zhli9w2FNxxgshuuAEt0/F9Wq34eymHVAY7 O/5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wpfpI9sEMExB2FpHiQVGvr2Sa8u+aQIaDKmeFmjYQfE=; b=1ScEy2RnsUVT2PDRMKXewWL34KgRdDAnOp0lj81VCn5Qic6FqPLFmHS4m+T2uBinW8 a9esSVjeJfN8+p3lk4r7kwf+qEsCDZeol1NnlAnVcU3ibHABBzmeZuEeUAu2iJexfEwN qUdMISAW3cnbDlcDKeY/9YauuH96FBQh7fJEubuhVqUD9MKzIhrS/QCm+yVBMq1AC6lb z8qp7t7XDssBDFxqim7xMxPrxKSwNJndgUl3WpwxiMCrSw7UKXwUUPZ6U4Vp+Hgxrn9W gfRQPSgkW9SN9YqiJfTodR+XF65CfMGIHIKwdt8wzskZuyVYI0Qc4YeEqawIkxIaMXd6 tLAA== X-Gm-Message-State: ANoB5pmMghrVYD1TuMvCSWDexDK5T/VEnGLeF7HIESd2EJuVBn4ihz+a RrY/jgrHujo3aF0VDAgsL/Y= X-Google-Smtp-Source: AA0mqf7qg4MYJdIl+BHHNDWIV5dLJtUH9GHETCW4Ppux8Iu6PmK0iqbApUAv9X843cccv1V/n8bNlw== X-Received: by 2002:a05:6a00:1893:b0:56b:8282:b165 with SMTP id x19-20020a056a00189300b0056b8282b165mr1519603pfh.69.1669049606458; Mon, 21 Nov 2022 08:53:26 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id ix11-20020a170902f80b00b001788ccecbf5sm9992317plb.31.2022.11.21.08.53.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Nov 2022 08:53:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file From: Yuan Fu In-Reply-To: <83k03o2vb2.fsf@gnu.org> Date: Mon, 21 Nov 2022 08:53:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <83k03o2vb2.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59415 Cc: 59415@debbugs.gnu.org, Theodor Thornhill X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Nov 21, 2022, at 7:15 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Sun, 20 Nov 2022 17:27:16 -0800 >> Cc: Eli Zaretskii , >> 59415@debbugs.gnu.org >>=20 >> I pushed a change that uses treesit-node-on. Now scrolling in most = parts of the buffer is pretty fast. Scrolling around 194770 is still = laggy, because the node we get from treesit-node-on is still too large. = I tried some heuristics but they didn=E2=80=99t work very well, IMO = because tree-sitter couldn=E2=80=99t parse that part of the code very = well. The code should observe a structure like {{}, {}, {}, {}, {}, =E2=80= =A6} where there are tens thousands of inner brackets, so ideally we = only need to grab the {}=E2=80=99s in the region we want to fontify. But = tree-sitter seems to understand it in some weird structure and we still = end up with very large nodes, which is far larger than the region we = want to fontify and is slow to query. >>=20 >> I=E2=80=99ll try to improve it further in the future, but for now I = think it=E2=80=99s good enough (because in most cases fontification is = pretty fast). >=20 > Agreed. >=20 > Thanks, I think we can close the bug now. >=20 > What do you think about enlarging treesit-max-buffer-size as I = proposed > up-thread? Yeah we should do it, but to what value though? 40MB? Yuan From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 21 12:17:30 2022 Received: (at 59415) by debbugs.gnu.org; 21 Nov 2022 17:17:30 +0000 Received: from localhost ([127.0.0.1]:48694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxAQA-00067Q-KC for submit@debbugs.gnu.org; Mon, 21 Nov 2022 12:17:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxAQ8-00067A-Px for 59415@debbugs.gnu.org; Mon, 21 Nov 2022 12:17:25 -0500 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 1oxAQ3-0002Ty-Bn; Mon, 21 Nov 2022 12:17:19 -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=eTH+Dvd76ODGFUYDr81Cmsy+D4UipGj64eHhJxLQbSI=; b=BjxXjgEoX1Km TgeBzPhaByYTecuRg/oeB/j7ebkyEUVQl1QQDB2U4js3faPLtbEa/KY/5wXP+WMoqKT0PpX6nwsks sUYDvVgr+be5fS2LdPd4VeYazTDlf3XYFUrREwCoEyG4x54RHVA/8292bJVqG/sqI7IHOLUoLvkjy Z0uv1ZMe/3zcmAJqJJnbPOpYagHd3ggWfBhYmIN8LP5FygdLEvTxGh5fK9BqsRLkWX510vz0ZNHTq n5BFixIILlKldMsBMyy7nhgq4RP3L/jP6lYGhlzIvKmDyRSti2N4Qif6MM31HbSqrX+O+AXdQ3qhp i32QANmsRUCuktZo4Q8aQQ==; 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 1oxAQ2-0006mn-RR; Mon, 21 Nov 2022 12:17:19 -0500 Date: Mon, 21 Nov 2022 19:17:31 +0200 Message-Id: <83a64k2pn8.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Mon, 21 Nov 2022 08:53:25 -0800) Subject: Re: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file 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> <83k03o2vb2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59415 Cc: 59415@debbugs.gnu.org, theo@thornhill.no X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Mon, 21 Nov 2022 08:53:25 -0800 > Cc: Theodor Thornhill , > 59415@debbugs.gnu.org > > > What do you think about enlarging treesit-max-buffer-size as I proposed > > up-thread? > > Yeah we should do it, but to what value though? 40MB? My suggestion was 15 MiB on 32-bit systems and 40 MiB on 64-bit systems. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 22 02:32:08 2022 Received: (at 59415) by debbugs.gnu.org; 22 Nov 2022 07:32:08 +0000 Received: from localhost ([127.0.0.1]:49541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxNlI-0007kb-9k for submit@debbugs.gnu.org; Tue, 22 Nov 2022 02:32:08 -0500 Received: from mail-pg1-f176.google.com ([209.85.215.176]:38585) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxNlG-0007k4-80; Tue, 22 Nov 2022 02:32:07 -0500 Received: by mail-pg1-f176.google.com with SMTP id 130so13357690pgc.5; Mon, 21 Nov 2022 23:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QDcYw25VDp+B2sK2o+npHcTgnF3OrB3riQ4C6C+w+vU=; b=RkUybs+V1aFJt77+cok5Oo0n3FIY+Ly4OdhaPaAvHgQvghA6UtUNwzilGASaikk4q4 L5lFmjCxPAOkzmsPl1NKepy67/pT9nYXreSuexk2TXKrYZ+TsEZoMzHj2DuaEcHeYJVb pf3r9SAEOFgcx43WiSvlkRGDDptuq568wdkz4TCw6+QZKuNPI9E/zNJ7GpbrTGyo4wwx MhLMoEmLnEHYJU5kp/waAyah0H/BN5iligxy4BFwSUYuAcOQ/gnoPNubW+D2+citt65I 8hYN/KUkF4PzKbj2EdwyCFCPsPlQShlDFhQxTFTvA6Et4FpSln1DvGceFKlD2qdDgLOm 3Uqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QDcYw25VDp+B2sK2o+npHcTgnF3OrB3riQ4C6C+w+vU=; b=SVO0JJUtRa0Z1g7XpYU5CJjR379B2NCnYf1Vdn2UGsSeK7f2IjxR0csLWmCZC5b09N HB4C0Jm2k/KnL5MXO2U/lOAW5frh8JrKVdRsGfOqNSCNBbu0W7XhRnpWBvim+D/eJp4z Lsc47XGVRvetXt9sdZnBafsZ1fb54TjAo90HXoFfZ9lc9+yQ4m4Fk3LIVONwwGX2V+TX jUumgOGHyp8l+DfKS8xVwTl6+hVCibFQmM8wXUvUCVMQbBJhGKHn5e5jViGphsK33AMm 3kpIBfH0IAvNIkyWT6q5/2+p6haNEWU1AKnoeyVga6lMVGGoCxXI3J9urqxG3njr/uUb VpnQ== X-Gm-Message-State: ANoB5pltdnuTa7fsVMoNIR6Y56IZyWYrPgRPXIINKAvFhXSJW6qfdj7R BzVNO5ALNQY75fgwnwtt3S0= X-Google-Smtp-Source: AA0mqf4z8Eg1+a5joCutVWC6nwSW8M/YWR0FiS3Ie/cs0fzCi8t5/RcuklC9//aBcBPrVLrtgWYwBg== X-Received: by 2002:aa7:8429:0:b0:556:d001:b830 with SMTP id q9-20020aa78429000000b00556d001b830mr2958686pfn.62.1669102320207; Mon, 21 Nov 2022 23:32:00 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id c16-20020a170903235000b00186f0f59c85sm5295233plh.235.2022.11.21.23.31.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Nov 2022 23:31:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file From: Yuan Fu In-Reply-To: <83a64k2pn8.fsf@gnu.org> Date: Mon, 21 Nov 2022 23:31:57 -0800 Content-Transfer-Encoding: 7bit Message-Id: 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> <83k03o2vb2.fsf@gnu.org> <83a64k2pn8.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59415 Cc: 59415@debbugs.gnu.org, Theodor Thornhill , 59415-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Nov 21, 2022, at 9:17 AM, Eli Zaretskii wrote: > >> From: Yuan Fu >> Date: Mon, 21 Nov 2022 08:53:25 -0800 >> Cc: Theodor Thornhill , >> 59415@debbugs.gnu.org >> >>> What do you think about enlarging treesit-max-buffer-size as I proposed >>> up-thread? >> >> Yeah we should do it, but to what value though? 40MB? > > My suggestion was 15 MiB on 32-bit systems and 40 MiB on 64-bit systems. Cool, changed, will push soon. From unknown Sat Jun 21 10:34:47 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 20 Dec 2022 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator