* bug#64830: 29.1; C++ treesitter mode no coloration @ 2023-07-24 9:13 David Come 2023-07-24 12:32 ` Eli Zaretskii 2024-08-14 17:35 ` bug#64830: 30.0.50 " Alan Mackenzie 0 siblings, 2 replies; 33+ messages in thread From: David Come @ 2023-07-24 9:13 UTC (permalink / raw) To: 64830 [-- Attachment #1: Type: text/plain, Size: 15256 bytes --] When opening a C++ file with major mode c++-ts-mode, there is not coloration In the Messsage buffer, I see Error during redisplay: (jit-lock-function 14) signaled (treesit-query-error "Node type error at" 99 "(true) @font-lock-constant-face (false) @font-lock-constant-face (null) @font-lock-constant-face (nullptr) @font-lock-constant-face" "Debug the query with `treesit-query-validate'") [2 times] In GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2023-07-24 built on ubuntu Repository revision: 31cef9a4eac01fff5ff4fcb89d7e2b7815e93bad Repository branch: HEAD Windowing system distributor 'The X.Org Foundation', version 11.0.12013000 System Description: Ubuntu 20.04.6 LTS Configured using: 'configure --prefix /usr/local --with-native-compilation --without-pgtk --with-json --with-gnutls --with-rsvg --without-xwidgets --with-toolkit-scroll-bars --without-xaw3d --without-mailutils --without-pop --with-tree-sitter 'CFLAGS=-O3 -mtune=native -march=native -fomit-frame-pointer'' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Magit Minor modes in effect: global-company-mode: t company-mode: t which-key-mode: t counsel-projectile-mode: t global-treesit-auto-mode: t recentf-mode: t winner-mode: t treemacs-icons-dired-mode: t dap-tooltip-mode: t dap-ui-many-windows-mode: t dap-ui-mode: t lsp-treemacs-sync-mode: t treemacs-filewatch-mode: t treemacs-follow-mode: t treemacs-git-mode: t treemacs-fringe-indicator-mode: t dap-auto-configure-mode: t dap-mode: t bury-successful-compilation: t yas-global-mode: t yas-minor-mode: t all-the-icons-ivy-rich-mode: t ivy-rich-mode: t projectile-mode: t counsel-mode: t ivy-mode: t gcmh-mode: t global-whitespace-cleanup-mode: t engine-mode: t unkillable-scratch: t dimmer-mode: t windmove-mode: t global-undo-tree-mode: t undo-tree-mode: t global-git-commit-mode: t magit-auto-revert-mode: t global-auto-revert-mode: t shell-dirtrack-mode: t server-mode: t volatile-highlights-mode: t override-global-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t column-number-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: /home/dcome/.emacs.d/elpa/transient-20230723.1411/transient hides /home/dcome/source/emacs-29-rc1/lisp/transient Features: (shadow sort mail-extr emacsbug magit-extras display-line-numbers make-mode tramp tramp-loaddefs trampver tramp-integration tramp-compat mule-util treemacs-bookmarks treemacs-tags magit-bookmark bookmark lsp-diagnostics company-cmake company-keywords company-dabbrev-code company-dabbrev company-files company-yasnippet company-capf company lsp-headerline lsp-icons lsp-modeline astyle reformatter lsp-ui lsp-ui-flycheck lsp-ui-doc lsp-ui-imenu lsp-ui-peek lsp-ui-sideline flycheck lsp-ui-util which-key view lsp-zig lsp-tilt lsp-steep lsp-svelte lsp-sqls lsp-ruby-syntax-tree lsp-ruby-lsp lsp-yaml lsp-xml lsp-vimscript lsp-vhdl lsp-volar lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v lsp-typeprof lsp-ttcn3 lsp-toml lsp-terraform lsp-tex lsp-sorbet lsp-solargraph lsp-semgrep lsp-rust lsp-rf lsp-ruff-lsp lsp-remark lsp-racket lsp-r lsp-purescript lsp-pylsp lsp-pyls lsp-pwsh lsp-php lsp-pls lsp-perlnavigator lsp-perl lsp-openscad lsp-ocaml lsp-magik lsp-nix lsp-nim lsp-nginx lsp-mint lsp-marksman lsp-markdown lsp-lua lsp-kotlin lsp-json lsp-javascript lsp-idris lsp-haxe lsp-groovy lsp-hack lsp-graphql lsp-glsl lsp-gleam lsp-go lsp-completion lsp-gdscript lsp-fsharp lsp-fortran lsp-eslint lsp-erlang lsp-emmet lsp-elixir lsp-elm lsp-dockerfile lsp-dhall lsp-d lsp-css lsp-csharp lsp-crystal lsp-credo lsp-cmake lsp-clojure lsp-semantic-tokens lsp-clangd lsp-beancount lsp-bash lsp-astro lsp-awk lsp-ansible lsp-angular lsp-ada lsp-actionscript c-ts-mode hideshow counsel-projectile oc-basic ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus nnheader range ol-docview doc-view jka-compr image-mode exif ol-bibtex bibtex iso8601 ol-bbdb ol-w3m ol-doi org-link-doi org-agenda time emacsql emacsql-compiler ghub-graphql treepy gsexp ghub url-http url-gw url-auth let-alist gnutls treesit-auto tree-sitter-langs tree-sitter-langs-build tar-mode arc-mode archive-mode tree-sitter-hl tree-sitter tree-sitter-load tree-sitter-cli tsc tsc-dyn tsc-dyn-get dired-aux tsc-obsolete register-list dockerfile-mode sh-script smie executable groovy-mode dts-mode afternoon-theme py-autopep8 lsp-haskell haskell-mode haskell-cabal haskell-utils haskell-font-lock haskell-indentation haskell-string haskell-sort-imports haskell-lexeme haskell-align-imports haskell-complete-module haskell-ghc-support flymake-proc flymake dabbrev haskell-customize dashboard dashboard-widgets recentf ob-shell ob-org org-bullets the-org-mode-expansions org-element org-persist org-id org-refile avl-tree org org-macro org-pcomplete org-list org-footnote org-faces org-entities ob-emacs-lisp org-table org-loaddefs cal-menu calendar cal-loaddefs winner move-text helpful cc-langs trace edebug debug backtrace info-look find-func elisp-refs ivy-avy link-hint ffap goto-addr ibuffer-vc treemacs-magit treemacs-icons-dired treemacs-projectile dap-mouse dap-ui lsp-treemacs lsp-treemacs-generic lsp-treemacs-themes treemacs-treelib treemacs treemacs-header-line treemacs-compatibility treemacs-mode treemacs-interface treemacs-persistence treemacs-filewatch-mode treemacs-follow-mode treemacs-rendering treemacs-annotations treemacs-async treemacs-workspaces treemacs-dom treemacs-visuals treemacs-fringe-indicator pulse treemacs-faces treemacs-icons treemacs-scope treemacs-themes treemacs-core-utils pfuture hl-line treemacs-logging treemacs-customization treemacs-macros gdb-mi bindat gud bui bui-list bui-info bui-entry bui-core bui-history bui-button bui-utils lsp-lens dap-python dap-mode dap-tasks dap-launch lsp-docker yaml posframe dap-overlays lsp-mode lsp-protocol tree-widget network-stream nsm inline ht f f-shortdoc ivy-xref cmake-font-lock cmake-mode rst bury-successful-compilation qml-mode flyspell ispell ivy-yasnippet auto-yasnippet haskell-snippets yasnippet-snippets yasnippet all-the-icons-ivy-rich all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons ivy-rich projectile ido counsel-fd counsel-test counsel-test-pytest counsel-test-ctest counsel-test-core counsel xdg swiper ivy delsel ivy-faces ivy-overlay colir async mermaid-mode protobuf-mode rotate d2-mode ob ob-tangle ol org-src ob-ref ob-lob ob-table ob-exp ob-comint ob-core org-cycle org-fold org-fold-core ob-eval org-keys oc org-compat org-version org-macs major-mode-hydra kill-or-bury-alive gcmh json-mode json-snatcher js-mode-expansions js c-ts-common treesit cc-mode-expansions cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs dired-subtree dired-hacks-utils rainbow-mode rainbow-delimiters smart-forward whitespace-cleanup-mode whitespace engine-mode miniedit expand-region yaml-mode-expansions text-mode-expansions er-basic-expansions expand-region-core expand-region-custom zetteldeft ace-window avy deft iedit iedit-lib goto-line-preview unkillable-scratch markdown-mode noutline outline dimmer face-remap color windmove sentence-navigation ample-regexps swap-buffers quail cl annotate rg files-x rg-info-hack rg-menu rg-ibuffer rg-result wgrep-rg wgrep rg-history rg-header ibuf-ext ibuffer ibuffer-loaddefs grep compile 0xc quelpa-use-package quelpa lisp-mnt help-fns radix-tree undo-tree queue git-modes gitignore-mode gitconfig-mode conf-mode gitattributes-mode xterm-color magit-lfs diff-hl log-view vc-dir ewoc vc git-link thingatpt vdiff-magit magit-ediff ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util git-timemachine vc-git vc-dispatcher magit-submodule magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff git-commit log-edit message sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor shell pcomplete comint ansi-osc server ansi-color magit-mode transient magit-git magit-base magit-section format-spec cursor-sensor crm compat vdiff smerge-mode diff diff-mode pretty-hydra s dash repo gitlab-ci-mode yaml-mode use-package-hydra edmacro kmacro comp comp-cstr warnings etags fileloop generator xref project advice volatile-highlights paradox paradox-menu paradox-commit-list hydra ring lv cus-edit pp cus-load icons wid-edit paradox-execute paradox-github paradox-core spinner cl-extra help-mode use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key easy-mmode use-package-core finder-inf 0xc-autoloads afternoon-theme-autoloads all-the-icons-ivy-rich-autoloads all-the-icons-autoloads annotate-autoloads astyle-autoloads async-autoloads auto-yasnippet-autoloads bm-autoloads bury-successful-compilation-autoloads clang-format-autoloads cmake-font-lock-autoloads cmake-mode-autoloads company-autoloads counsel-fd-autoloads counsel-projectile-autoloads counsel-autoloads counsel-test-autoloads d2-mode-autoloads dap-mode-autoloads bui-autoloads dashboard-autoloads diff-hl-autoloads dimmer-autoloads dired-subtree-autoloads dired-hacks-utils-autoloads dockerfile-mode-autoloads dts-mode-autoloads easy-hugo-autoloads engine-mode-autoloads flycheck-autoloads flyspell-correct-ivy-autoloads flyspell-correct-autoloads forge-autoloads closql-autoloads emacsql-autoloads gcmh-autoloads ghub-autoloads git-link-autoloads git-modes-autoloads git-timemachine-autoloads gitlab-ci-mode-autoloads goto-line-preview-autoloads groovy-mode-autoloads haskell-snippets-autoloads helpful-autoloads elisp-refs-autoloads highlight-indent-guides-autoloads ibuffer-vc-autoloads iedit-autoloads ivy-avy-autoloads ivy-rich-autoloads ivy-xref-autoloads ivy-yasnippet-autoloads json-mode-autoloads rx json-snatcher-autoloads kill-or-bury-alive-autoloads kotlin-mode-autoloads kotlin-ts-mode-autoloads link-hint-autoloads lsp-docker-autoloads lsp-haskell-autoloads haskell-mode-autoloads lsp-ivy-autoloads lsp-treemacs-autoloads lsp-ui-autoloads lsp-mode-autoloads f-autoloads magit-lfs-autoloads major-mode-hydra-autoloads markdown-mode-autoloads mermaid-mode-autoloads miniedit-autoloads move-text-autoloads olivetti-autoloads org-bullets-autoloads paradox-autoloads pipenv-autoloads load-env-vars-autoloads pkg-info-autoloads epl-autoloads popup-autoloads pretty-hydra-autoloads protobuf-mode-autoloads py-autopep8-autoloads pyvenv-autoloads qml-mode-autoloads quelpa-use-package-autoloads quelpa-autoloads rainbow-delimiters-autoloads rainbow-mode-autoloads reformatter-autoloads register-list-autoloads repo-autoloads request-autoloads rg-autoloads rotate-autoloads sentence-navigation-autoloads ample-regexps-autoloads shell-pop-autoloads smart-comment-autoloads smart-forward-autoloads expand-region-autoloads spinner-autoloads swap-buffers-autoloads swiper-autoloads ivy-autoloads tree-sitter-langs-autoloads tree-sitter-autoloads treemacs-icons-dired-autoloads treemacs-magit-autoloads treemacs-projectile-autoloads treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads pfuture-autoloads s-autoloads projectile-autoloads treepy-autoloads treesit-auto-autoloads tsc-autoloads undo-tree-autoloads queue-autoloads unkillable-scratch-autoloads use-package-hydra-autoloads vdiff-magit-autoloads magit-autoloads pcase magit-section-autoloads git-commit-autoloads transient-autoloads dash-autoloads vdiff-autoloads hydra-autoloads lv-autoloads visual-regexp-steroids-autoloads visual-regexp-autoloads volatile-highlights-autoloads wgrep-autoloads which-key-autoloads whitespace-cleanup-mode-autoloads with-editor-autoloads info compat-autoloads xterm-color-autoloads yaml-autoloads yaml-mode-autoloads yasnippet-snippets-autoloads yasnippet-autoloads zetteldeft-autoloads ace-window-autoloads avy-autoloads deft-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd 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 theme-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 dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 1459818 925289) (symbols 48 74217 152) (strings 32 443096 123894) (string-bytes 1 15926874) (vectors 16 156046) (vector-slots 8 2896484 996131) (floats 8 2121 6640) (intervals 56 12743 9883) (buffers 984 42)) [-- Attachment #2: Type: text/html, Size: 23997 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 29.1; C++ treesitter mode no coloration 2023-07-24 9:13 bug#64830: 29.1; C++ treesitter mode no coloration David Come @ 2023-07-24 12:32 ` Eli Zaretskii 2024-08-14 17:35 ` bug#64830: 30.0.50 " Alan Mackenzie 1 sibling, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2023-07-24 12:32 UTC (permalink / raw) To: David Come, Yuan Fu, Theodor Thornhill; +Cc: 64830 merge 64830 64818 thanks > From: David Come <david.come@ageagle.com> > Date: Mon, 24 Jul 2023 09:13:33 +0000 > msip_labels: > > When opening a C++ file with major mode c++-ts-mode, there is not > coloration > > In the Messsage buffer, I see > > Error during redisplay: (jit-lock-function 14) signaled (treesit-query-error "Node type error at" 99 "(true) > @font-lock-constant-face (false) @font-lock-constant-face (null) @font-lock-constant-face (nullptr) > @font-lock-constant-face" "Debug the query with `treesit-query-validate'") [2 times] Thanks. This is the same issue as bug#64830; merged. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2023-07-24 9:13 bug#64830: 29.1; C++ treesitter mode no coloration David Come 2023-07-24 12:32 ` Eli Zaretskii @ 2024-08-14 17:35 ` Alan Mackenzie 2024-08-15 5:25 ` Eli Zaretskii 1 sibling, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2024-08-14 17:35 UTC (permalink / raw) To: 64830 Hello, Emacs. In my emacs-30 build (updated earlier today), C++ source in c++-ts-mode is not getting fontified, except for comments and preprocessor constructs. I think I'm using tree-sitter-cpp version 0.22.2 as downloaded from the Gentoo repository. Is there an easy way to check this from inside Emacs? This would appear to be bug 64818/64830, which are still open in debbugs. Shouldn't they be closed before the first/next emacs-30 pretest? -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-14 17:35 ` bug#64830: 30.0.50 " Alan Mackenzie @ 2024-08-15 5:25 ` Eli Zaretskii 2024-08-16 16:44 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-15 5:25 UTC (permalink / raw) To: Alan Mackenzie, Yuan Fu; +Cc: 64830 > Date: Wed, 14 Aug 2024 17:35:05 +0000 > From: Alan Mackenzie <acm@muc.de> > > Hello, Emacs. > > In my emacs-30 build (updated earlier today), C++ source in c++-ts-mode > is not getting fontified, except for comments and preprocessor > constructs. I cannot reproduce this, at least not with a random C++ source file I tried to. Does this happen for you in "emacs -Q" and for every C++ file? If this happens with any file and in 'emacs -Q", do you see redisplay error messages in *Messages*? If so, what are those messages? > I think I'm using tree-sitter-cpp version 0.22.2 as downloaded from the > Gentoo repository. Is there an easy way to check this from inside > Emacs? No, not AFAIK. And the problem is not the version of tree-sitter, it is usually the version of the C++ grammar library. Do you know the version of that one you have installed? > This would appear to be bug 64818/64830, which are still open in > debbugs. Shouldn't they be closed before the first/next emacs-30 > pretest? Those bugs were fixed. The reason they are not closed is that we raised a more general issue there, and that is not yet resolved. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-15 5:25 ` Eli Zaretskii @ 2024-08-16 16:44 ` Alan Mackenzie 2024-08-16 17:40 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2024-08-16 16:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, Yuan Fu Hello, Eli. On Thu, Aug 15, 2024 at 08:25:34 +0300, Eli Zaretskii wrote: > > Date: Wed, 14 Aug 2024 17:35:05 +0000 > > From: Alan Mackenzie <acm@muc.de> > > In my emacs-30 build (updated earlier today), C++ source in c++-ts-mode > > is not getting fontified, except for comments and preprocessor > > constructs. > I cannot reproduce this, at least not with a random C++ source file I > tried to. Does this happen for you in "emacs -Q" and for every C++ > file? Yes, and yes. Here's a recipe: Create the file ~/class-3.cc with the following contents: ///////////////////////////////////////////////////////////////////////// // foo class A { struct B { int i; }; struct B { int i; }; }; ///////////////////////////////////////////////////////////////////////// (i) emacs -Q (ii) M-x load-library <RET> c-ts-mode <RET> (iii) C-x C-f ~/class-3.cc <RET> The buffer, in c++-ts-mode, has no fontification apart from the comment on its first line. > If this happens with any file and in 'emacs -Q", do you see redisplay > error messages in *Messages*? If so, what are those messages? Yes, I see a single message after the above recipe. It's: Error during redisplay: (jit-lock-function 1) signaled (treesit-query-error "Node type error at" 677 "[\"_Atomic\" \"break\" \"case\" \"const\" \"continue\" \"default\" \"do\" \"else\" \"enum\" \"extern\" \"for\" \"goto\" \"if\" \"inline\" \"register\" \"restrict\" \"return\" \"sizeof\" \"static\" \"struct\" \"switch\" \"typedef\" \"union\" \"volatile\" \"while\" \"and\" \"and_eq\" \"bitand\" \"bitor\" \"catch\" \"class\" \"co_await\" \"co_return\" \"co_yield\" \"compl\" \"\concept\" \"consteval\" \"constexpr\" \"constinit\" \"decltype\" \"delete\" \"explicit\" \"final\" \"friend\" \"mutable\" \"namespace\" \"new\" \"noexcept\" \"not\" \"not_eq\" \"operator\" \"or\" \"or_eq\" \"override\" \"private\" \"protected\" \"public\" \"requires\" \"template\" \"throw\" \"try\" \"typename\" \"using\" \"xor\" \"xor_eq\"] @font-lock-keyword-face (auto) @font-lock-keyword-face (this) @font-lock-keyword-face (virtual) @font-lock-keyword-face" "Debug the query with `treesit-query-validate'") > > I think I'm using tree-sitter-cpp version 0.22.2 as downloaded from the > > Gentoo repository. Is there an easy way to check this from inside > > Emacs? > No, not AFAIK. And the problem is not the version of tree-sitter, it > is usually the version of the C++ grammar library. Do you know the > version of that one you have installed? I have libtree-sitter-cpp.so.0.14, built and installed on 2024-08-04. The package is (confusingly) called dev-libs/tree-sitter-cpp-0.22.2. > > This would appear to be bug 64818/64830, which are still open in > > debbugs. Shouldn't they be closed before the first/next emacs-30 > > pretest? > Those bugs were fixed. The reason they are not closed is that we > raised a more general issue there, and that is not yet resolved. OK. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-16 16:44 ` Alan Mackenzie @ 2024-08-16 17:40 ` Eli Zaretskii 2024-08-16 17:45 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-16 17:40 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 64830, casouri > Date: Fri, 16 Aug 2024 16:44:33 +0000 > Cc: Yuan Fu <casouri@gmail.com>, 64830@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > Create the file ~/class-3.cc with the following contents: > ///////////////////////////////////////////////////////////////////////// > // foo > class A > { > struct B { > int i; > }; > struct B { > int i; > }; > }; > ///////////////////////////////////////////////////////////////////////// > > (i) emacs -Q > (ii) M-x load-library <RET> c-ts-mode <RET> > (iii) C-x C-f ~/class-3.cc <RET> > > The buffer, in c++-ts-mode, has no fontification apart from the comment > on its first line. > > > If this happens with any file and in 'emacs -Q", do you see redisplay > > error messages in *Messages*? If so, what are those messages? > > Yes, I see a single message after the above recipe. It's: > > Error during redisplay: (jit-lock-function 1) signaled > (treesit-query-error "Node type error at" 677 "[\"_Atomic\" \"break\" > \"case\" \"const\" \"continue\" \"default\" \"do\" \"else\" \"enum\" > \"extern\" \"for\" \"goto\" \"if\" \"inline\" \"register\" \"restrict\" > \"return\" \"sizeof\" \"static\" \"struct\" \"switch\" \"typedef\" > \"union\" \"volatile\" \"while\" \"and\" \"and_eq\" \"bitand\" \"bitor\" > \"catch\" \"class\" \"co_await\" \"co_return\" \"co_yield\" \"compl\" > \"\concept\" \"consteval\" \"constexpr\" \"constinit\" \"decltype\" > \"delete\" \"explicit\" \"final\" \"friend\" \"mutable\" \"namespace\" > \"new\" \"noexcept\" \"not\" \"not_eq\" \"operator\" \"or\" \"or_eq\" > \"override\" \"private\" \"protected\" \"public\" \"requires\" > \"template\" \"throw\" \"try\" \"typename\" \"using\" \"xor\" > \"xor_eq\"] @font-lock-keyword-face (auto) @font-lock-keyword-face > (this) @font-lock-keyword-face (virtual) @font-lock-keyword-face" "Debug > the query with `treesit-query-validate'") > > > > I think I'm using tree-sitter-cpp version 0.22.2 as downloaded from the > > > Gentoo repository. Is there an easy way to check this from inside > > > Emacs? > > > No, not AFAIK. And the problem is not the version of tree-sitter, it > > is usually the version of the C++ grammar library. Do you know the > > version of that one you have installed? > > I have libtree-sitter-cpp.so.0.14, built and installed on 2024-08-04. > The package is (confusingly) called dev-libs/tree-sitter-cpp-0.22.2. I can reproduce this in Emacs 29, but not in the current emacs-30 branch. I think I also have libtree-sitter-cpp version 0.22.2, but I also tested with 0.22.3 and I see no problem there, either (with Emacs 30). So I wonder why you see this in Emacs 30. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-16 17:40 ` Eli Zaretskii @ 2024-08-16 17:45 ` Eli Zaretskii 2024-08-16 18:06 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-16 17:45 UTC (permalink / raw) To: acm; +Cc: 64830, casouri > Cc: 64830@debbugs.gnu.org, casouri@gmail.com > Date: Fri, 16 Aug 2024 20:40:07 +0300 > From: Eli Zaretskii <eliz@gnu.org> > > I can reproduce this in Emacs 29, but not in the current emacs-30 > branch. I think I also have libtree-sitter-cpp version 0.22.2, but I > also tested with 0.22.3 and I see no problem there, either (with Emacs > 30). So I wonder why you see this in Emacs 30. Maybe your Emacs 30 build is old? ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-16 17:45 ` Eli Zaretskii @ 2024-08-16 18:06 ` Alan Mackenzie 2024-08-16 18:27 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2024-08-16 18:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, acm, casouri Hello, Eli. On Fri, Aug 16, 2024 at 20:45:05 +0300, Eli Zaretskii wrote: > > Cc: 64830@debbugs.gnu.org, casouri@gmail.com > > Date: Fri, 16 Aug 2024 20:40:07 +0300 > > From: Eli Zaretskii <eliz@gnu.org> > > I can reproduce this in Emacs 29, but not in the current emacs-30 > > branch. I think I also have libtree-sitter-cpp version 0.22.2, but I > > also tested with 0.22.3 and I see no problem there, either (with Emacs > > 30). So I wonder why you see this in Emacs 30. > Maybe your Emacs 30 build is old? No. I updated it on Wednesday, the most recent commit I have being: commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, origin/emacs-30) Author: Eli Zaretskii <eliz@gnu.org> Date: Wed Aug 14 11:35:48 2024 +0300 Improve documentation of time-parsing functions .. I will update it right now and retry .... ..... DONE. It makes no difference. I don't understand either why I see this bug and you don't. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-16 18:06 ` Alan Mackenzie @ 2024-08-16 18:27 ` Eli Zaretskii 2024-08-20 3:46 ` Yuan Fu 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-16 18:27 UTC (permalink / raw) To: Alan Mackenzie, casouri; +Cc: 64830 > Date: Fri, 16 Aug 2024 18:06:31 +0000 > Cc: 64830@debbugs.gnu.org, casouri@gmail.com, acm@muc.de > From: Alan Mackenzie <acm@muc.de> > > > Maybe your Emacs 30 build is old? > > No. I updated it on Wednesday, the most recent commit I have being: > > commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, > origin/emacs-30) > Author: Eli Zaretskii <eliz@gnu.org> > Date: Wed Aug 14 11:35:48 2024 +0300 > > Improve documentation of time-parsing functions > > .. I will update it right now and retry .... > > ..... DONE. It makes no difference. I don't understand either why I see > this bug and you don't. Maybe try updating the C++ grammar library? Yuan, any ideas? ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-16 18:27 ` Eli Zaretskii @ 2024-08-20 3:46 ` Yuan Fu 2024-08-24 18:35 ` Yuan Fu 0 siblings, 1 reply; 33+ messages in thread From: Yuan Fu @ 2024-08-20 3:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, Alan Mackenzie > On Aug 16, 2024, at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> Date: Fri, 16 Aug 2024 18:06:31 +0000 >> Cc: 64830@debbugs.gnu.org, casouri@gmail.com, acm@muc.de >> From: Alan Mackenzie <acm@muc.de> >> >>> Maybe your Emacs 30 build is old? >> >> No. I updated it on Wednesday, the most recent commit I have being: >> >> commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, >> origin/emacs-30) >> Author: Eli Zaretskii <eliz@gnu.org> >> Date: Wed Aug 14 11:35:48 2024 +0300 >> >> Improve documentation of time-parsing functions >> >> .. I will update it right now and retry .... >> >> ..... DONE. It makes no difference. I don't understand either why I see >> this bug and you don't. > > Maybe try updating the C++ grammar library? > > Yuan, any ideas? Nothing obviously wrong from a glance. I’m very busy recently but I’ll have some time this week to look into this. Sorry for the delay :-) Yuan ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-20 3:46 ` Yuan Fu @ 2024-08-24 18:35 ` Yuan Fu 2024-08-24 19:38 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Yuan Fu @ 2024-08-24 18:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, Alan Mackenzie [-- Attachment #1: Type: text/plain, Size: 1377 bytes --] > On Aug 19, 2024, at 8:46 PM, Yuan Fu <casouri@gmail.com> wrote: > > > >> On Aug 16, 2024, at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> >>> Date: Fri, 16 Aug 2024 18:06:31 +0000 >>> Cc: 64830@debbugs.gnu.org, casouri@gmail.com, acm@muc.de >>> From: Alan Mackenzie <acm@muc.de> >>> >>>> Maybe your Emacs 30 build is old? >>> >>> No. I updated it on Wednesday, the most recent commit I have being: >>> >>> commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, >>> origin/emacs-30) >>> Author: Eli Zaretskii <eliz@gnu.org> >>> Date: Wed Aug 14 11:35:48 2024 +0300 >>> >>> Improve documentation of time-parsing functions >>> >>> .. I will update it right now and retry .... >>> >>> ..... DONE. It makes no difference. I don't understand either why I see >>> this bug and you don't. >> >> Maybe try updating the C++ grammar library? >> >> Yuan, any ideas? > > Nothing obviously wrong from a glance. I’m very busy recently but I’ll have some time this week to look into this. Sorry for the delay :-) > > Yuan Upon closer inspection, I think this is caused by a recent change in c-ts-mode font-lock rules, in 014aab9847a0d3d898cb8cbc7224143f2d741abb. Alan, could you do this: don’t upgrade your c++ grammar and try this patch, if I was right it should fix your problem. Thanks! Yuan [-- Attachment #2: cpp-font-lock.patch --] [-- Type: application/octet-stream, Size: 1832 bytes --] From a171709cadd915f48d6c8ed3f9e1e19f6a4fde19 Mon Sep 17 00:00:00 2001 From: Yuan Fu <casouri@gmail.com> Date: Sat, 24 Aug 2024 11:32:43 -0700 Subject: [PATCH] Fix c-ts-mode font-lock for older c++ grammar (bug#64830) * lisp/progmodes/c-ts-mode.el: (c-ts-mode--virtual-named-p): New function. (c-ts-mode--font-lock-settings): Use either keyword or named node depending on grammar version. --- lisp/progmodes/c-ts-mode.el | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el index 6c406a8acd9..66e4999677b 100644 --- a/lisp/progmodes/c-ts-mode.el +++ b/lisp/progmodes/c-ts-mode.el @@ -537,6 +537,16 @@ c-ts-mode--top-level-label-matcher (equal "function_definition" (treesit-node-type (treesit-node-parent parent))))) +;;; Grammar checks + +;; Ref: https://github.com/tree-sitter/tree-sitter-cpp/commit/c51ffe9d7b67aa9500db01c26d8c075cfe032d0f +(defun c-ts-mode--virtual-named-p () + "Return t if virtual is a named node instead of a keyword." + (ignore-errors + (progn + (treesit-query-compile 'c++ "(virtual) @cap") + t))) + ;;; Font-lock (defvar c-ts-mode--feature-list @@ -635,9 +645,11 @@ c-ts-mode--font-lock-settings :feature 'keyword `([,@(c-ts-mode--keywords mode)] @font-lock-keyword-face ,@(when (eq mode 'cpp) - '((auto) @font-lock-keyword-face + `((auto) @font-lock-keyword-face (this) @font-lock-keyword-face - (virtual) @font-lock-keyword-face))) + ,@(if (c-ts-mode--virtual-named-p) + '((virtual) @font-lock-keyword-face) + '("virtual" @font-lock-keyword-face))))) :language mode :feature 'operator -- 2.39.5 (Apple Git-151) ^ permalink raw reply related [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-24 18:35 ` Yuan Fu @ 2024-08-24 19:38 ` Alan Mackenzie 2024-08-24 20:43 ` Yuan Fu 0 siblings, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2024-08-24 19:38 UTC (permalink / raw) To: Yuan Fu; +Cc: 64830, Eli Zaretskii Hello, Yuan. On Sat, Aug 24, 2024 at 11:35:36 -0700, Yuan Fu wrote: > > On Aug 19, 2024, at 8:46 PM, Yuan Fu <casouri@gmail.com> wrote: > >> On Aug 16, 2024, at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >>> Date: Fri, 16 Aug 2024 18:06:31 +0000 > >>> Cc: 64830@debbugs.gnu.org, casouri@gmail.com, acm@muc.de > >>> From: Alan Mackenzie <acm@muc.de> > >>>> Maybe your Emacs 30 build is old? > >>> No. I updated it on Wednesday, the most recent commit I have being: > >>> commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, > >>> origin/emacs-30) > >>> Author: Eli Zaretskii <eliz@gnu.org> > >>> Date: Wed Aug 14 11:35:48 2024 +0300 > >>> Improve documentation of time-parsing functions > >>> .. I will update it right now and retry .... > >>> ..... DONE. It makes no difference. I don't understand either why I see > >>> this bug and you don't. > >> Maybe try updating the C++ grammar library? > >> Yuan, any ideas? > > Nothing obviously wrong from a glance. I’m very busy recently but I’ll have some time this week to look into this. Sorry for the delay :-) > > Yuan > Upon closer inspection, I think this is caused by a recent change in c-ts-mode font-lock rules, in 014aab9847a0d3d898cb8cbc7224143f2d741abb. > Alan, could you do this: don’t upgrade your c++ grammar and try this patch, if I was right it should fix your problem. Thanks! I updated my emacs-30 branch, checked that that commit was included, and rebuilt it. The problem still exists on my copy of Emacs 30. :-( > Yuan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-24 19:38 ` Alan Mackenzie @ 2024-08-24 20:43 ` Yuan Fu 2024-08-25 2:19 ` Alan Mackenzie 0 siblings, 1 reply; 33+ messages in thread From: Yuan Fu @ 2024-08-24 20:43 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 64830, Eli Zaretskii > On Aug 24, 2024, at 12:38 PM, Alan Mackenzie <acm@muc.de> wrote: > > Hello, Yuan. > > On Sat, Aug 24, 2024 at 11:35:36 -0700, Yuan Fu wrote: > > >>> On Aug 19, 2024, at 8:46 PM, Yuan Fu <casouri@gmail.com> wrote: > > > >>>> On Aug 16, 2024, at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >>>>> Date: Fri, 16 Aug 2024 18:06:31 +0000 >>>>> Cc: 64830@debbugs.gnu.org, casouri@gmail.com, acm@muc.de >>>>> From: Alan Mackenzie <acm@muc.de> > >>>>>> Maybe your Emacs 30 build is old? > >>>>> No. I updated it on Wednesday, the most recent commit I have being: > >>>>> commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, >>>>> origin/emacs-30) >>>>> Author: Eli Zaretskii <eliz@gnu.org> >>>>> Date: Wed Aug 14 11:35:48 2024 +0300 > >>>>> Improve documentation of time-parsing functions > >>>>> .. I will update it right now and retry .... > >>>>> ..... DONE. It makes no difference. I don't understand either why I see >>>>> this bug and you don't. > >>>> Maybe try updating the C++ grammar library? > >>>> Yuan, any ideas? > >>> Nothing obviously wrong from a glance. I’m very busy recently but I’ll have some time this week to look into this. Sorry for the delay :-) > >>> Yuan > >> Upon closer inspection, I think this is caused by a recent change in c-ts-mode font-lock rules, in 014aab9847a0d3d898cb8cbc7224143f2d741abb. > >> Alan, could you do this: don’t upgrade your c++ grammar and try this patch, if I was right it should fix your problem. Thanks! > > I updated my emacs-30 branch, checked that that commit was included, and > rebuilt it. The problem still exists on my copy of Emacs 30. :-( No no I mean apply the attached patch and see if it fixes the problem. The commit hash I mentioned is the source of the bug, not the fix ;-) Yuan ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-24 20:43 ` Yuan Fu @ 2024-08-25 2:19 ` Alan Mackenzie 2024-08-25 4:54 ` Eli Zaretskii 2024-08-25 22:40 ` Yuan Fu 0 siblings, 2 replies; 33+ messages in thread From: Alan Mackenzie @ 2024-08-25 2:19 UTC (permalink / raw) To: Yuan Fu; +Cc: 64830, Eli Zaretskii Hello, Yuan. On Sat, Aug 24, 2024 at 13:43:25 -0700, Yuan Fu wrote: > > On Aug 24, 2024, at 12:38 PM, Alan Mackenzie <acm@muc.de> wrote: > > On Sat, Aug 24, 2024 at 11:35:36 -0700, Yuan Fu wrote: > >>> On Aug 19, 2024, at 8:46 PM, Yuan Fu <casouri@gmail.com> wrote: > >>>> On Aug 16, 2024, at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >>>>> Date: Fri, 16 Aug 2024 18:06:31 +0000 > >>>>> Cc: 64830@debbugs.gnu.org, casouri@gmail.com, acm@muc.de > >>>>> From: Alan Mackenzie <acm@muc.de> > >>>>>> Maybe your Emacs 30 build is old? > >>>>> No. I updated it on Wednesday, the most recent commit I have being: > >>>>> commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, > >>>>> origin/emacs-30) > >>>>> Author: Eli Zaretskii <eliz@gnu.org> > >>>>> Date: Wed Aug 14 11:35:48 2024 +0300 > >>>>> Improve documentation of time-parsing functions > >>>>> .. I will update it right now and retry .... > >>>>> ..... DONE. It makes no difference. I don't understand either > >>>>> why I see this bug and you don't. > >>>> Maybe try updating the C++ grammar library? > >>>> Yuan, any ideas? > >>> Nothing obviously wrong from a glance. I’m very busy recently but > >>> I’ll have some time this week to look into this. Sorry for the > >>> delay :-) > >>> Yuan > >> Upon closer inspection, I think this is caused by a recent change in > >> c-ts-mode font-lock rules, in > >> 014aab9847a0d3d898cb8cbc7224143f2d741abb. > >> Alan, could you do this: don’t upgrade your c++ grammar and try this > >> patch, if I was right it should fix your problem. Thanks! > > I updated my emacs-30 branch, checked that that commit was included, > > and rebuilt it. The problem still exists on my copy of Emacs 30. > > :-( > No no I mean apply the attached patch and see if it fixes the problem. > The commit hash I mentioned is the source of the bug, not the fix ;-) Sorry about the misunderstanding. I've now applied your patch, the one whose first hunk's header is: @@ -537,6 +537,16 @@ c-ts-mode--top-level-label-matcher , but it unfortunately doesn't solve the bug. On templates-21.cc, one of the test files from CC Mode, on doing M-x c++-ts-mode, there is no fontification at all. In *Messages* we have Error during redisplay: (jit-lock-function 1) signaled (treesit-query-error "Node type error at" 677 "[\"_Atomic\" \"break\" \"case\" \"const\" \"continue\" \"default\" \"do\" \"else\" \"enum\" \"extern\" \"for\" \"goto\" \"if\" \"inline\" \"register\" \"restrict\" \"return\" \"sizeof\" \"static\" \"struct\" \"switch\" \"typedef\" \"union\" \"volatile\" \"while\" \"and\" \"and_eq\" \"bitand\" \"bitor\" \"catch\" \"class\" \"co_await\" \"co_return\" \"co_yield\" \"compl\" \"concept\" \"consteval\" \"constexpr\" \"constinit\" \"decltype\" \"delete\" \"explicit\" \"final\" \"friend\" \"mutable\" \"namespace\" \"new\" \"noexcept\" \"not\" \"not_eq\" \"operator\" \"or\" \"or_eq\" \"override\" \"private\" \"protected\" \"public\" \"requires\" \"template\" \"throw\" \"try\" \"typename\" \"using\" \"xor\" \"xor_eq\"] @font-lock-keyword-face (auto) @font-lock-keyword-face (this) @font-lock-keyword-face (virtual) @font-lock-keyword-face" "Debug the query with `treesit-query-validate'") That "Node type error at" 677 isn't a buffer position - the buffer is only 325 characters long. Is there anything else I could do to help, here? > Yuan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-25 2:19 ` Alan Mackenzie @ 2024-08-25 4:54 ` Eli Zaretskii 2024-08-25 12:08 ` Alan Mackenzie 2024-08-25 22:40 ` Yuan Fu 1 sibling, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-25 4:54 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 64830, casouri > Date: Sun, 25 Aug 2024 02:19:28 +0000 > Cc: Eli Zaretskii <eliz@gnu.org>, 64830@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > I've now applied your patch, the one whose first hunk's header is: > > @@ -537,6 +537,16 @@ c-ts-mode--top-level-label-matcher > > , but it unfortunately doesn't solve the bug. On templates-21.cc, one of > the test files from CC Mode, on doing M-x c++-ts-mode, there is no > fontification at all. In *Messages* we have > > Error during redisplay: (jit-lock-function 1) signaled > (treesit-query-error "Node type error at" 677 "[\"_Atomic\" \"break\" > \"case\" \"const\" \"continue\" \"default\" \"do\" \"else\" \"enum\" > \"extern\" \"for\" \"goto\" \"if\" \"inline\" \"register\" \"restrict\" > \"return\" \"sizeof\" \"static\" \"struct\" \"switch\" \"typedef\" > \"union\" \"volatile\" \"while\" \"and\" \"and_eq\" \"bitand\" \"bitor\" > \"catch\" \"class\" \"co_await\" \"co_return\" \"co_yield\" \"compl\" > \"concept\" \"consteval\" \"constexpr\" \"constinit\" \"decltype\" > \"delete\" \"explicit\" \"final\" \"friend\" \"mutable\" \"namespace\" > \"new\" \"noexcept\" \"not\" \"not_eq\" \"operator\" \"or\" \"or_eq\" > \"override\" \"private\" \"protected\" \"public\" \"requires\" > \"template\" \"throw\" \"try\" \"typename\" \"using\" \"xor\" \"xor_eq\"] > @font-lock-keyword-face (auto) @font-lock-keyword-face (this) > @font-lock-keyword-face (virtual) @font-lock-keyword-face" "Debug the > query with `treesit-query-validate'") > > That "Node type error at" 677 isn't a buffer position - the buffer is > only 325 characters long. > > Is there anything else I could do to help, here? AFAIR, you still didn't respond to my questions about the version of the C++ grammar library you are using, nor tried to upgrade to the latest version of that grammar library. FTR, I'm using tree-sitter version 0.20.8 and grammar library from their Git repository as of June 17 (this is version 0.22.2 of the grammar library with a couple of changes after that version). I have no problems with displaying C++ files whatsoever, and *Messages* is clean. I also tried the latest version of the grammar library (0.22.3), and didn't see any problems there, either. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-25 4:54 ` Eli Zaretskii @ 2024-08-25 12:08 ` Alan Mackenzie 2024-08-25 12:17 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Alan Mackenzie @ 2024-08-25 12:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, casouri Hello, Eli. On Sun, Aug 25, 2024 at 07:54:43 +0300, Eli Zaretskii wrote: > > Date: Sun, 25 Aug 2024 02:19:28 +0000 > > Cc: Eli Zaretskii <eliz@gnu.org>, 64830@debbugs.gnu.org > > From: Alan Mackenzie <acm@muc.de> > > I've now applied your patch, the one whose first hunk's header is: > > @@ -537,6 +537,16 @@ c-ts-mode--top-level-label-matcher > > , but it unfortunately doesn't solve the bug. On templates-21.cc, one of > > the test files from CC Mode, on doing M-x c++-ts-mode, there is no > > fontification at all. In *Messages* we have > > Error during redisplay: (jit-lock-function 1) signaled > > (treesit-query-error "Node type error at" 677 "[\"_Atomic\" \"break\" > > \"case\" \"const\" \"continue\" \"default\" \"do\" \"else\" \"enum\" > > \"extern\" \"for\" \"goto\" \"if\" \"inline\" \"register\" \"restrict\" > > \"return\" \"sizeof\" \"static\" \"struct\" \"switch\" \"typedef\" > > \"union\" \"volatile\" \"while\" \"and\" \"and_eq\" \"bitand\" \"bitor\" > > \"catch\" \"class\" \"co_await\" \"co_return\" \"co_yield\" \"compl\" > > \"concept\" \"consteval\" \"constexpr\" \"constinit\" \"decltype\" > > \"delete\" \"explicit\" \"final\" \"friend\" \"mutable\" \"namespace\" > > \"new\" \"noexcept\" \"not\" \"not_eq\" \"operator\" \"or\" \"or_eq\" > > \"override\" \"private\" \"protected\" \"public\" \"requires\" > > \"template\" \"throw\" \"try\" \"typename\" \"using\" \"xor\" \"xor_eq\"] > > @font-lock-keyword-face (auto) @font-lock-keyword-face (this) > > @font-lock-keyword-face (virtual) @font-lock-keyword-face" "Debug the > > query with `treesit-query-validate'") > > That "Node type error at" 677 isn't a buffer position - the buffer is > > only 325 characters long. > > Is there anything else I could do to help, here? > AFAIR, you still didn't respond to my questions about the version of > the C++ grammar library you are using, nor tried to upgrade to the > latest version of that grammar library. I thought I said that right at the beginning, in my first post on this thread. I'm using tree-sitter-cpp version 0.22.2, and version 0.22.6 of tree-sitter itself. > FTR, I'm using tree-sitter version 0.20.8 and grammar library from > their Git repository as of June 17 (this is version 0.22.2 of the > grammar library with a couple of changes after that version). I have > no problems with displaying C++ files whatsoever, and *Messages* is > clean. I also tried the latest version of the grammar library > (0.22.3), and didn't see any problems there, either. I haven't been able to find a download facility on the tree-sitter-cpp page at Github. Did you download a ready built version of tree-sitter-cpp 0.22.3, or did you have to build it yourself from sources? -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-25 12:08 ` Alan Mackenzie @ 2024-08-25 12:17 ` Eli Zaretskii 0 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2024-08-25 12:17 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 64830, casouri > Date: Sun, 25 Aug 2024 12:08:33 +0000 > Cc: casouri@gmail.com, 64830@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > > FTR, I'm using tree-sitter version 0.20.8 and grammar library from > > their Git repository as of June 17 (this is version 0.22.2 of the > > grammar library with a couple of changes after that version). I have > > no problems with displaying C++ files whatsoever, and *Messages* is > > clean. I also tried the latest version of the grammar library > > (0.22.3), and didn't see any problems there, either. > > I haven't been able to find a download facility on the tree-sitter-cpp > page at Github. Did you download a ready built version of > tree-sitter-cpp 0.22.3, or did you have to build it yourself from > sources? The latter. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-25 2:19 ` Alan Mackenzie 2024-08-25 4:54 ` Eli Zaretskii @ 2024-08-25 22:40 ` Yuan Fu 2024-08-26 17:25 ` Alan Mackenzie 1 sibling, 1 reply; 33+ messages in thread From: Yuan Fu @ 2024-08-25 22:40 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 64830, Eli Zaretskii > On Aug 24, 2024, at 7:19 PM, Alan Mackenzie <acm@muc.de> wrote: > > Hello, Yuan. > > On Sat, Aug 24, 2024 at 13:43:25 -0700, Yuan Fu wrote: > > >>> On Aug 24, 2024, at 12:38 PM, Alan Mackenzie <acm@muc.de> wrote: >>> On Sat, Aug 24, 2024 at 11:35:36 -0700, Yuan Fu wrote: >>>>> On Aug 19, 2024, at 8:46 PM, Yuan Fu <casouri@gmail.com> wrote: >>>>>> On Aug 16, 2024, at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >>>>>>> Date: Fri, 16 Aug 2024 18:06:31 +0000 >>>>>>> Cc: 64830@debbugs.gnu.org, casouri@gmail.com, acm@muc.de >>>>>>> From: Alan Mackenzie <acm@muc.de> > >>>>>>>> Maybe your Emacs 30 build is old? > >>>>>>> No. I updated it on Wednesday, the most recent commit I have being: > >>>>>>> commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, >>>>>>> origin/emacs-30) >>>>>>> Author: Eli Zaretskii <eliz@gnu.org> >>>>>>> Date: Wed Aug 14 11:35:48 2024 +0300 > >>>>>>> Improve documentation of time-parsing functions > >>>>>>> .. I will update it right now and retry .... > >>>>>>> ..... DONE. It makes no difference. I don't understand either >>>>>>> why I see this bug and you don't. > >>>>>> Maybe try updating the C++ grammar library? > >>>>>> Yuan, any ideas? > >>>>> Nothing obviously wrong from a glance. I’m very busy recently but >>>>> I’ll have some time this week to look into this. Sorry for the >>>>> delay :-) > >>>>> Yuan > >>>> Upon closer inspection, I think this is caused by a recent change in >>>> c-ts-mode font-lock rules, in >>>> 014aab9847a0d3d898cb8cbc7224143f2d741abb. > >>>> Alan, could you do this: don’t upgrade your c++ grammar and try this >>>> patch, if I was right it should fix your problem. Thanks! > >>> I updated my emacs-30 branch, checked that that commit was included, >>> and rebuilt it. The problem still exists on my copy of Emacs 30. >>> :-( > >> No no I mean apply the attached patch and see if it fixes the problem. >> The commit hash I mentioned is the source of the bug, not the fix ;-) > > Sorry about the misunderstanding. > > I've now applied your patch, the one whose first hunk's header is: > > @@ -537,6 +537,16 @@ c-ts-mode--top-level-label-matcher > > , but it unfortunately doesn't solve the bug. On templates-21.cc, one of > the test files from CC Mode, on doing M-x c++-ts-mode, there is no > fontification at all. In *Messages* we have > > Error during redisplay: (jit-lock-function 1) signaled > (treesit-query-error "Node type error at" 677 "[\"_Atomic\" \"break\" > \"case\" \"const\" \"continue\" \"default\" \"do\" \"else\" \"enum\" > \"extern\" \"for\" \"goto\" \"if\" \"inline\" \"register\" \"restrict\" > \"return\" \"sizeof\" \"static\" \"struct\" \"switch\" \"typedef\" > \"union\" \"volatile\" \"while\" \"and\" \"and_eq\" \"bitand\" \"bitor\" > \"catch\" \"class\" \"co_await\" \"co_return\" \"co_yield\" \"compl\" > \"concept\" \"consteval\" \"constexpr\" \"constinit\" \"decltype\" > \"delete\" \"explicit\" \"final\" \"friend\" \"mutable\" \"namespace\" > \"new\" \"noexcept\" \"not\" \"not_eq\" \"operator\" \"or\" \"or_eq\" > \"override\" \"private\" \"protected\" \"public\" \"requires\" > \"template\" \"throw\" \"try\" \"typename\" \"using\" \"xor\" \"xor_eq\"] > @font-lock-keyword-face (auto) @font-lock-keyword-face (this) > @font-lock-keyword-face (virtual) @font-lock-keyword-face" "Debug the > query with `treesit-query-validate'") > > That "Node type error at" 677 isn't a buffer position - the buffer is > only 325 characters long. > > Is there anything else I could do to help, here? Yes, could you try evaluating this three forms, and tell me their result? (treesit-query-validate 'cpp '("virtual" @cap)) (treesit-query-validate 'cpp '((virtual) @cap)) (treesit-query-validate 'cpp '((auto) @font-lock-keyword-face (this) @font-lock-keyword-face (virtual) @font-lock-keyword-face)) To give more context, in the error you see, position 677 is a position in the query string, which points to the (virtual) part. That leads me to believe your grammar doesn’t recognize the (virtual) query. So in the patch I provided earlier, I added a function that tests whether the grammar recognizes (virtual), and if not, it uses the “virtual” query instead. The difference between (virtual) and “virtual” in the query is that (virtual) is a named node, and “virtual” is a keyword. I’m still not sure why you have this problem though, because I built libtree-sitter-cpp v0.22.2 and v0.22.0 and tested them locally, and they recognize (virtual) just fine. Anyway, evaluating those three forms will tell us what’s going on. And to your question for building tree-sitter grammar, you can use the script at https://github.com/casouri/tree-sitter-module You can either run ./batch to build all the languages, or run ./build cpp to only build for cpp. Then just copy the grammar file in dist to ~/.emacs.d/tree-sitter. Yuan ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-25 22:40 ` Yuan Fu @ 2024-08-26 17:25 ` Alan Mackenzie 2024-08-26 17:51 ` Eli Zaretskii 2024-08-27 11:03 ` Eli Zaretskii 0 siblings, 2 replies; 33+ messages in thread From: Alan Mackenzie @ 2024-08-26 17:25 UTC (permalink / raw) To: Yuan Fu; +Cc: 64830, Eli Zaretskii Hello, Yuan. On Sun, Aug 25, 2024 at 15:40:31 -0700, Yuan Fu wrote: > > On Aug 24, 2024, at 7:19 PM, Alan Mackenzie <acm@muc.de> wrote: > > Hello, Yuan. > > On Sat, Aug 24, 2024 at 13:43:25 -0700, Yuan Fu wrote: > >>> On Aug 24, 2024, at 12:38 PM, Alan Mackenzie <acm@muc.de> wrote: > >>> On Sat, Aug 24, 2024 at 11:35:36 -0700, Yuan Fu wrote: > >>>>> On Aug 19, 2024, at 8:46 PM, Yuan Fu <casouri@gmail.com> wrote: > >>>>>> On Aug 16, 2024, at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >>>>>>> Date: Fri, 16 Aug 2024 18:06:31 +0000 > >>>>>>> Cc: 64830@debbugs.gnu.org, casouri@gmail.com, acm@muc.de > >>>>>>> From: Alan Mackenzie <acm@muc.de> > >>>>>>>> Maybe your Emacs 30 build is old? > >>>>>>> No. I updated it on Wednesday, the most recent commit I have being: > >>>>>>> commit 9bedb957bebdca99b1bb96f58ea790e20ed48dee (HEAD -> emacs-30, > >>>>>>> origin/emacs-30) > >>>>>>> Author: Eli Zaretskii <eliz@gnu.org> > >>>>>>> Date: Wed Aug 14 11:35:48 2024 +0300 > >>>>>>> Improve documentation of time-parsing functions > >>>>>>> .. I will update it right now and retry .... > >>>>>>> ..... DONE. It makes no difference. I don't understand either > >>>>>>> why I see this bug and you don't. > >>>>>> Maybe try updating the C++ grammar library? > >>>>>> Yuan, any ideas? > >>>>> Nothing obviously wrong from a glance. I’m very busy recently but > >>>>> I’ll have some time this week to look into this. Sorry for the > >>>>> delay :-) > >>>>> Yuan > >>>> Upon closer inspection, I think this is caused by a recent change in > >>>> c-ts-mode font-lock rules, in > >>>> 014aab9847a0d3d898cb8cbc7224143f2d741abb. > >>>> Alan, could you do this: don’t upgrade your c++ grammar and try this > >>>> patch, if I was right it should fix your problem. Thanks! > >>> I updated my emacs-30 branch, checked that that commit was included, > >>> and rebuilt it. The problem still exists on my copy of Emacs 30. > >>> :-( > >> No no I mean apply the attached patch and see if it fixes the problem. > >> The commit hash I mentioned is the source of the bug, not the fix ;-) > > Sorry about the misunderstanding. > > I've now applied your patch, the one whose first hunk's header is: > > @@ -537,6 +537,16 @@ c-ts-mode--top-level-label-matcher > > , but it unfortunately doesn't solve the bug. On templates-21.cc, one of > > the test files from CC Mode, on doing M-x c++-ts-mode, there is no > > fontification at all. In *Messages* we have > > Error during redisplay: (jit-lock-function 1) signaled > > (treesit-query-error "Node type error at" 677 "[\"_Atomic\" \"break\" > > \"case\" \"const\" \"continue\" \"default\" \"do\" \"else\" \"enum\" > > \"extern\" \"for\" \"goto\" \"if\" \"inline\" \"register\" \"restrict\" > > \"return\" \"sizeof\" \"static\" \"struct\" \"switch\" \"typedef\" > > \"union\" \"volatile\" \"while\" \"and\" \"and_eq\" \"bitand\" \"bitor\" > > \"catch\" \"class\" \"co_await\" \"co_return\" \"co_yield\" \"compl\" > > \"concept\" \"consteval\" \"constexpr\" \"constinit\" \"decltype\" > > \"delete\" \"explicit\" \"final\" \"friend\" \"mutable\" \"namespace\" > > \"new\" \"noexcept\" \"not\" \"not_eq\" \"operator\" \"or\" \"or_eq\" > > \"override\" \"private\" \"protected\" \"public\" \"requires\" > > \"template\" \"throw\" \"try\" \"typename\" \"using\" \"xor\" \"xor_eq\"] > > @font-lock-keyword-face (auto) @font-lock-keyword-face (this) > > @font-lock-keyword-face (virtual) @font-lock-keyword-face" "Debug the > > query with `treesit-query-validate'") > > That "Node type error at" 677 isn't a buffer position - the buffer is > > only 325 characters long. > > Is there anything else I could do to help, here? > Yes, could you try evaluating this three forms, and tell me their result? Done. But see below, first! > (treesit-query-validate 'cpp '("virtual" @cap)) "QUERY is valid" > (treesit-query-validate 'cpp '((virtual) @cap)) In *Tree-Sitter check query*, I got: Node type error at: 2 (virtual) @cap In the reponse area, I got: t .. > (treesit-query-validate 'cpp '((auto) @font-lock-keyword-face > (this) @font-lock-keyword-face > (virtual) @font-lock-keyword-face)) In *Tree-Sitter check query*, I got: Node type error at: 64 (auto) @font-lock-keyword-face (this) @font-lock-keyword-face (virtual) @font-lock-keyword-face , and again in the response area: t .. > To give more context, in the error you see, position 677 is a position > in the query string, which points to the (virtual) part. That leads me > to believe your grammar doesn’t recognize the (virtual) query. So in > the patch I provided earlier, I added a function that tests whether the > grammar recognizes (virtual), and if not, it uses the “virtual” query > instead. The difference between (virtual) and “virtual” in the query is > that (virtual) is a named node, and “virtual” is a keyword. > I’m still not sure why you have this problem though, because I built > libtree-sitter-cpp v0.22.2 and v0.22.0 and tested them locally, and > they recognize (virtual) just fine. Anyway, evaluating those three > forms will tell us what’s going on. I downloaded my libtree-sitter-cpp.so.0.14 from my GNU/Linux distribution, Gentoo. It regards itself as dev-libs/tree-sitter-cpp version 0.22.2. Might it be worthwhile adding some functionality to Emacs whereby a user could check which versions of grammar libraries she's got? Or is there something like that already? > And to your question for building tree-sitter grammar, you can use the > script at https://github.com/casouri/tree-sitter-module > You can either run ./batch to build all the languages, or run ./build > cpp to only build for cpp. Then just copy the grammar file in dist to > ~/.emacs.d/tree-sitter. Ah, that's it! I didn't know the grammar library in use was the one in ~/.emacs/tree-sitter. There, I've got -rwxr-xr-x 1 acm acm 2319888 Jan 19 2023 libtree-sitter-cpp.so , which is very old. In my /usr/lib64, I've got lrwxrwxrwx 1 root root 26 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so.0 -> libtree-sitter-cpp.so.0.14 lrwxrwxrwx 1 root root 23 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so -> libtree-sitter-cpp.so.0 -rwxr-xr-x 1 root root 3175712 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so.0.14 Why do we have this extra complication with ~/.emacs.d/tree-sitter as a location for libraries? In GNU/Linux distributions (well, in Gentoo at any rate), newly downloaded libraries are put into /usr/lib64, so that anybody naively updating a grammar library is going to have it masked out by the old one still in ~/.emacs.d/tree-sitter. Maybe I don't understand the library mechanism as well as I ought to. > Yuan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-26 17:25 ` Alan Mackenzie @ 2024-08-26 17:51 ` Eli Zaretskii 2024-08-26 19:50 ` Alan Mackenzie 2024-08-27 11:03 ` Eli Zaretskii 1 sibling, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-26 17:51 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 64830, casouri > Date: Mon, 26 Aug 2024 17:25:34 +0000 > Cc: Eli Zaretskii <eliz@gnu.org>, 64830@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > Ah, that's it! I didn't know the grammar library in use was the one in > ~/.emacs/tree-sitter. There, I've got > > -rwxr-xr-x 1 acm acm 2319888 Jan 19 2023 libtree-sitter-cpp.so > > , which is very old. In my /usr/lib64, I've got > > lrwxrwxrwx 1 root root 26 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so.0 -> libtree-sitter-cpp.so.0.14 > lrwxrwxrwx 1 root root 23 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so -> libtree-sitter-cpp.so.0 > -rwxr-xr-x 1 root root 3175712 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so.0.14 > > Why do we have this extra complication with ~/.emacs.d/tree-sitter as a > location for libraries? In GNU/Linux distributions (well, in Gentoo at > any rate), newly downloaded libraries are put into /usr/lib64, so that > anybody naively updating a grammar library is going to have it masked out > by the old one still in ~/.emacs.d/tree-sitter. Maybe I don't understand > the library mechanism as well as I ought to. We support grammar libraries in ~/.emacs.d/tree-sitter so that users could easily install versions of grammar libraries different from what their sysadmins decide to install. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-26 17:51 ` Eli Zaretskii @ 2024-08-26 19:50 ` Alan Mackenzie 2024-08-26 22:25 ` Stefan Kangas 2024-08-27 12:01 ` Eli Zaretskii 0 siblings, 2 replies; 33+ messages in thread From: Alan Mackenzie @ 2024-08-26 19:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, casouri Hello, Eli. On Mon, Aug 26, 2024 at 20:51:00 +0300, Eli Zaretskii wrote: > > Date: Mon, 26 Aug 2024 17:25:34 +0000 > > Cc: Eli Zaretskii <eliz@gnu.org>, 64830@debbugs.gnu.org > > From: Alan Mackenzie <acm@muc.de> > > Ah, that's it! I didn't know the grammar library in use was the one in > > ~/.emacs/tree-sitter. There, I've got > > -rwxr-xr-x 1 acm acm 2319888 Jan 19 2023 libtree-sitter-cpp.so > > , which is very old. In my /usr/lib64, I've got > > lrwxrwxrwx 1 root root 26 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so.0 -> libtree-sitter-cpp.so.0.14 > > lrwxrwxrwx 1 root root 23 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so -> libtree-sitter-cpp.so.0 > > -rwxr-xr-x 1 root root 3175712 Aug 4 18:13 /usr/lib64/libtree-sitter-cpp.so.0.14 > > Why do we have this extra complication with ~/.emacs.d/tree-sitter as a > > location for libraries? In GNU/Linux distributions (well, in Gentoo at > > any rate), newly downloaded libraries are put into /usr/lib64, so that > > anybody naively updating a grammar library is going to have it masked out > > by the old one still in ~/.emacs.d/tree-sitter. Maybe I don't understand > > the library mechanism as well as I ought to. > We support grammar libraries in ~/.emacs.d/tree-sitter so that users > could easily install versions of grammar libraries different from what > their sysadmins decide to install. Ah, OK. Seems like a good reason. How about outputting a message looking something like this: Loading /home/acm/.emacs.d/tree-sitter/libtree-sitter.so ....Done .. This wouldn't get in the way, yet might well prevent some of the problems I've been having over the last few days. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-26 19:50 ` Alan Mackenzie @ 2024-08-26 22:25 ` Stefan Kangas 2024-08-27 1:58 ` Yuan Fu 2024-08-27 12:01 ` Eli Zaretskii 1 sibling, 1 reply; 33+ messages in thread From: Stefan Kangas @ 2024-08-26 22:25 UTC (permalink / raw) To: Alan Mackenzie, Eli Zaretskii; +Cc: 64830, casouri Alan Mackenzie <acm@muc.de> writes: > How about outputting a message looking something like this: > > Loading /home/acm/.emacs.d/tree-sitter/libtree-sitter.so ....Done > > .. This wouldn't get in the way, yet might well prevent some of the > problems I've been having over the last few days. Makes sense to me, FWIW. Perhaps we should have a knob to enable/disable such messages though. I'm also not sure what should be the default. Perhaps we should experiment with it and take a final decision when we have some experience with using it. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-26 22:25 ` Stefan Kangas @ 2024-08-27 1:58 ` Yuan Fu 2024-08-27 12:09 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Yuan Fu @ 2024-08-27 1:58 UTC (permalink / raw) To: Stefan Kangas; +Cc: 64830, Alan Mackenzie, Eli Zaretskii > On Aug 26, 2024, at 3:25 PM, Stefan Kangas <stefankangas@gmail.com> wrote: > > Alan Mackenzie <acm@muc.de> writes: > >> How about outputting a message looking something like this: >> >> Loading /home/acm/.emacs.d/tree-sitter/libtree-sitter.so ....Done >> >> .. This wouldn't get in the way, yet might well prevent some of the >> problems I've been having over the last few days. > > Makes sense to me, FWIW. Perhaps we should have a knob to > enable/disable such messages though. > > I'm also not sure what should be the default. Perhaps we should > experiment with it and take a final decision when we have some > experience with using it. Yeah, that’ll be a very useful feature. To determining which grammar my Emacs instance loaded, I had to delete the object file and see if Emacs complains it can’t find any grammar. I think it’s fine to print this to message buffer by default, it’ll only happen once and we already do such things for loading a elisp file. I searched a bit and it seems ldaddr can find the location of a loaded shared library. Doesn’t seem hard to implement. I also want a lisp function that can return the location of a loaded grammar file, would that be an overkill if we have the aforementioned printing? Yuan ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-27 1:58 ` Yuan Fu @ 2024-08-27 12:09 ` Eli Zaretskii 2024-08-28 5:36 ` Yuan Fu 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-27 12:09 UTC (permalink / raw) To: Yuan Fu; +Cc: 64830, acm, stefankangas > From: Yuan Fu <casouri@gmail.com> > Date: Mon, 26 Aug 2024 18:58:13 -0700 > Cc: Alan Mackenzie <acm@muc.de>, > Eli Zaretskii <eliz@gnu.org>, > 64830@debbugs.gnu.org > > I also want a lisp function that can return the location of a loaded grammar file, would that be an overkill if we have the aforementioned printing? Where/when would such a function be used? ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-27 12:09 ` Eli Zaretskii @ 2024-08-28 5:36 ` Yuan Fu 2024-08-28 12:33 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Yuan Fu @ 2024-08-28 5:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, Alan Mackenzie, Stefan Kangas [-- Attachment #1: Type: text/plain, Size: 656 bytes --] > On Aug 27, 2024, at 5:09 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Yuan Fu <casouri@gmail.com> >> Date: Mon, 26 Aug 2024 18:58:13 -0700 >> Cc: Alan Mackenzie <acm@muc.de>, >> Eli Zaretskii <eliz@gnu.org>, >> 64830@debbugs.gnu.org >> >> I also want a lisp function that can return the location of a loaded grammar file, would that be an overkill if we have the aforementioned printing? > > Where/when would such a function be used? For debugging. Eg, to verify that Emacs loaded the grammar file I think it loaded. Something like (treesit-grammar-location 'c) ; => “/opt/local/lib/libtree-sitter-c.dylib”. Yuan [-- Attachment #2: show-location.patch --] [-- Type: application/octet-stream, Size: 6726 bytes --] From c64dc3e287e3db009589fb27d07d658baca9fe66 Mon Sep 17 00:00:00 2001 From: Yuan Fu <casouri@gmail.com> Date: Tue, 27 Aug 2024 22:31:42 -0700 Subject: [PATCH] Add Ftreesit_grammar_location * src/treesit.c (treesit_loaded_lang): New struct. (treesit_load_language): Return a struct instead of just the language object. The struct contains both the language object and the path to the shared library. (Ftreesit_language_available_p, Ftreesit_language_abi_version) (treesit_ensure_query_compiled, Ftreesit_parser_create): Update call of treesit_load_language. (Ftreesit_grammar_location): New function. --- src/treesit.c | 68 +++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 55 insertions(+), 13 deletions(-) diff --git a/src/treesit.c b/src/treesit.c index 5aedca44489..56cf8a1075a 100644 --- a/src/treesit.c +++ b/src/treesit.c @@ -19,6 +19,7 @@ Copyright (C) 2021-2024 Free Software Foundation, Inc. You should have received a copy of the GNU General Public License along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */ +#include <dlfcn.h> #include <config.h> #include "lisp.h" #include "buffer.h" @@ -491,6 +492,14 @@ treesit_initialize (void) \f /*** Loading language library */ +struct treesit_loaded_lang +{ + /* The language object. */ + TSLanguage *lang; + /* The path of the shared library. */ + const char *path; +}; + /* Translate a symbol treesit-<lang> to a C name treesit_<lang>. */ static void treesit_symbol_to_c_name (char *symbol_name) @@ -575,7 +584,7 @@ treesit_load_language_push_for_each_suffix (Lisp_Object lib_base_name, If error occurs, return NULL and fill SIGNAL_SYMBOL and SIGNAL_DATA with values suitable for xsignal. */ -static TSLanguage * +static struct treesit_loaded_lang treesit_load_language (Lisp_Object language_symbol, Lisp_Object *signal_symbol, Lisp_Object *signal_data) { @@ -626,6 +635,7 @@ treesit_load_language (Lisp_Object language_symbol, dynlib_handle_ptr handle; const char *error; Lisp_Object error_list = Qnil; + struct treesit_loaded_lang loaded_lang = { NULL, NULL }; tail = path_candidates; error = NULL; @@ -650,7 +660,7 @@ treesit_load_language (Lisp_Object language_symbol, mismatch. */ *signal_symbol = Qtreesit_load_language_error; *signal_data = Fcons (Qnot_found, Fnreverse (error_list)); - return NULL; + return loaded_lang; } /* Load TSLanguage. */ @@ -672,7 +682,7 @@ treesit_load_language (Lisp_Object language_symbol, { *signal_symbol = Qtreesit_load_language_error; *signal_data = list2 (Qsymbol_error, build_string (error)); - return NULL; + return loaded_lang; } TSLanguage *lang = (*langfn) (); @@ -685,9 +695,15 @@ treesit_load_language (Lisp_Object language_symbol, *signal_symbol = Qtreesit_load_language_error; *signal_data = list2 (Qversion_mismatch, make_fixnum (ts_language_version (lang))); - return NULL; + return loaded_lang; } - return lang; + + Dl_info info; + if (dladdr(langfn, &info)) + loaded_lang.path = info.dli_fname; + + loaded_lang.lang = lang; + return loaded_lang; } DEFUN ("treesit-language-available-p", Ftreesit_language_available_p, @@ -704,7 +720,9 @@ DEFUN ("treesit-language-available-p", Ftreesit_language_available_p, treesit_initialize (); Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; - if (treesit_load_language (language, &signal_symbol, &signal_data) == NULL) + struct treesit_loaded_lang loaded_lang + = treesit_load_language (language, &signal_symbol, &signal_data); + if (loaded_lang.lang == NULL) { if (NILP (detail)) return Qnil; @@ -750,9 +768,9 @@ DEFUN ("treesit-language-abi-version", Ftreesit_language_abi_version, { Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; - TSLanguage *ts_language = treesit_load_language (language, - &signal_symbol, - &signal_data); + struct treesit_loaded_lang lang + = treesit_load_language (language, &signal_symbol, &signal_data); + TSLanguage *ts_language = lang.lang; if (ts_language == NULL) return Qnil; uint32_t version = ts_language_version (ts_language); @@ -760,6 +778,27 @@ DEFUN ("treesit-language-abi-version", Ftreesit_language_abi_version, } } +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location, + Streesit_grammar_location, + 1, 1, 0, + doc: /* Return the path to the grammar file for LANGUAGE. + +If LANGUAGE isn't loaded yet, load it first. If the langauge can't be +loaded or the path couldn't be found, return nil. */) + (Lisp_Object language) +{ + CHECK_SYMBOL (language); + + Lisp_Object signal_symbol = Qnil; + Lisp_Object signal_data = Qnil; + struct treesit_loaded_lang lang + = treesit_load_language (language, &signal_symbol, &signal_data); + + if (!lang.lang || !lang.path) return Qnil; + + return build_string (lang.path); +} + \f /*** Parsing functions */ @@ -1305,8 +1344,9 @@ treesit_ensure_query_compiled (Lisp_Object query, Lisp_Object *signal_symbol, Lisp_Object language = XTS_COMPILED_QUERY (query)->language; /* This is the main reason why we compile query lazily: to avoid loading languages early. */ - TSLanguage *treesit_lang = treesit_load_language (language, signal_symbol, - signal_data); + struct treesit_loaded_lang lang + = treesit_load_language (language, signal_symbol, signal_data); + TSLanguage *treesit_lang = lang.lang; if (treesit_lang == NULL) return NULL; @@ -1477,8 +1517,9 @@ DEFUN ("treesit-parser-create", Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; TSParser *parser = ts_parser_new (); - TSLanguage *lang = treesit_load_language (language, &signal_symbol, - &signal_data); + struct treesit_loaded_lang loaded_lang + = treesit_load_language (language, &signal_symbol, &signal_data); + TSLanguage *lang = loaded_lang.lang; if (lang == NULL) xsignal (signal_symbol, signal_data); /* We check language version when loading a language, so this should @@ -4275,6 +4316,7 @@ cons (REGEXP . FN), which is a combination of a regexp and a predicate defsubr (&Streesit_language_available_p); defsubr (&Streesit_library_abi_version); defsubr (&Streesit_language_abi_version); + defsubr (&Streesit_grammar_location); defsubr (&Streesit_parser_p); defsubr (&Streesit_node_p); -- 2.39.5 (Apple Git-151) ^ permalink raw reply related [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-28 5:36 ` Yuan Fu @ 2024-08-28 12:33 ` Eli Zaretskii 2024-08-29 4:54 ` Yuan Fu 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-28 12:33 UTC (permalink / raw) To: Yuan Fu; +Cc: 64830, acm, stefankangas > From: Yuan Fu <casouri@gmail.com> > Date: Tue, 27 Aug 2024 22:36:46 -0700 > Cc: Stefan Kangas <stefankangas@gmail.com>, > Alan Mackenzie <acm@muc.de>, > 64830@debbugs.gnu.org > > +struct treesit_loaded_lang > +{ > + /* The language object. */ > + TSLanguage *lang; > + /* The path of the shared library. */ > + const char *path; Gnu Coding Standard frowns on using "path" for anything except PATH-style directory lists. Please use "filename" or "fname" or something like that instead. > + Dl_info info; > + if (dladdr(langfn, &info)) > + loaded_lang.path = info.dli_fname; dladdr is non-portable. We have dynlib_addr instead, and since treesit.c correctly uses dynlib.c functions already, using dynlib_addr is only natural. > + if (!lang.lang || !lang.path) return Qnil; > + > + return build_string (lang.path); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think we should do return DECODE_FILE (make_unibyte_string (lang.filename, strlen (lang.filename)); instead, because dynlib_addr (and dladdr as well) return encoded file names. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-28 12:33 ` Eli Zaretskii @ 2024-08-29 4:54 ` Yuan Fu 2024-08-29 6:01 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Yuan Fu @ 2024-08-29 4:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, Alan Mackenzie, Stefan Kangas [-- Attachment #1: Type: text/plain, Size: 1297 bytes --] > On Aug 28, 2024, at 5:33 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Yuan Fu <casouri@gmail.com> >> Date: Tue, 27 Aug 2024 22:36:46 -0700 >> Cc: Stefan Kangas <stefankangas@gmail.com>, >> Alan Mackenzie <acm@muc.de>, >> 64830@debbugs.gnu.org >> >> +struct treesit_loaded_lang >> +{ >> + /* The language object. */ >> + TSLanguage *lang; >> + /* The path of the shared library. */ >> + const char *path; > > Gnu Coding Standard frowns on using "path" for anything except > PATH-style directory lists. Please use "filename" or "fname" or > something like that instead. > >> + Dl_info info; >> + if (dladdr(langfn, &info)) >> + loaded_lang.path = info.dli_fname; > > dladdr is non-portable. We have dynlib_addr instead, and since > treesit.c correctly uses dynlib.c functions already, using dynlib_addr > is only natural. > >> + if (!lang.lang || !lang.path) return Qnil; >> + >> + return build_string (lang.path); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I think we should do > > return > DECODE_FILE (make_unibyte_string (lang.filename, strlen (lang.filename)); > > instead, because dynlib_addr (and dladdr as well) return encoded file > names. Ah, thanks for the review! TIL. Here’s the revised patch. Yuan [-- Attachment #2: grammar-location.patch --] [-- Type: application/octet-stream, Size: 6681 bytes --] From 97374b55f2a786bf24db63bf206ccf217927de4f Mon Sep 17 00:00:00 2001 From: Yuan Fu <casouri@gmail.com> Date: Tue, 27 Aug 2024 22:31:42 -0700 Subject: [PATCH] Add Ftreesit_grammar_location * src/treesit.c (treesit_loaded_lang): New struct. (treesit_load_language): Return a struct instead of just the language object. The struct contains both the language object and the path to the shared library. (Ftreesit_language_available_p, Ftreesit_language_abi_version) (treesit_ensure_query_compiled, Ftreesit_parser_create): Update call of treesit_load_language. (Ftreesit_grammar_location): New function. --- src/treesit.c | 68 +++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 55 insertions(+), 13 deletions(-) diff --git a/src/treesit.c b/src/treesit.c index 5aedca44489..09f4aeb0b99 100644 --- a/src/treesit.c +++ b/src/treesit.c @@ -22,6 +22,7 @@ Copyright (C) 2021-2024 Free Software Foundation, Inc. #include <config.h> #include "lisp.h" #include "buffer.h" +#include "coding.h" #include "treesit.h" @@ -491,6 +492,14 @@ treesit_initialize (void) \f /*** Loading language library */ +struct treesit_loaded_lang +{ + /* The language object. */ + TSLanguage *lang; + /* The path to the shared library. */ + const char *filename; +}; + /* Translate a symbol treesit-<lang> to a C name treesit_<lang>. */ static void treesit_symbol_to_c_name (char *symbol_name) @@ -575,7 +584,7 @@ treesit_load_language_push_for_each_suffix (Lisp_Object lib_base_name, If error occurs, return NULL and fill SIGNAL_SYMBOL and SIGNAL_DATA with values suitable for xsignal. */ -static TSLanguage * +static struct treesit_loaded_lang treesit_load_language (Lisp_Object language_symbol, Lisp_Object *signal_symbol, Lisp_Object *signal_data) { @@ -626,6 +635,7 @@ treesit_load_language (Lisp_Object language_symbol, dynlib_handle_ptr handle; const char *error; Lisp_Object error_list = Qnil; + struct treesit_loaded_lang loaded_lang = { NULL, NULL }; tail = path_candidates; error = NULL; @@ -650,7 +660,7 @@ treesit_load_language (Lisp_Object language_symbol, mismatch. */ *signal_symbol = Qtreesit_load_language_error; *signal_data = Fcons (Qnot_found, Fnreverse (error_list)); - return NULL; + return loaded_lang; } /* Load TSLanguage. */ @@ -672,7 +682,7 @@ treesit_load_language (Lisp_Object language_symbol, { *signal_symbol = Qtreesit_load_language_error; *signal_data = list2 (Qsymbol_error, build_string (error)); - return NULL; + return loaded_lang; } TSLanguage *lang = (*langfn) (); @@ -685,9 +695,14 @@ treesit_load_language (Lisp_Object language_symbol, *signal_symbol = Qtreesit_load_language_error; *signal_data = list2 (Qversion_mismatch, make_fixnum (ts_language_version (lang))); - return NULL; + return loaded_lang; } - return lang; + + const char *sym; + dynlib_addr((void (*) (void)) langfn, &loaded_lang.filename, &sym); + + loaded_lang.lang = lang; + return loaded_lang; } DEFUN ("treesit-language-available-p", Ftreesit_language_available_p, @@ -704,7 +719,9 @@ DEFUN ("treesit-language-available-p", Ftreesit_language_available_p, treesit_initialize (); Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; - if (treesit_load_language (language, &signal_symbol, &signal_data) == NULL) + struct treesit_loaded_lang loaded_lang + = treesit_load_language (language, &signal_symbol, &signal_data); + if (loaded_lang.lang == NULL) { if (NILP (detail)) return Qnil; @@ -750,9 +767,9 @@ DEFUN ("treesit-language-abi-version", Ftreesit_language_abi_version, { Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; - TSLanguage *ts_language = treesit_load_language (language, - &signal_symbol, - &signal_data); + struct treesit_loaded_lang lang + = treesit_load_language (language, &signal_symbol, &signal_data); + TSLanguage *ts_language = lang.lang; if (ts_language == NULL) return Qnil; uint32_t version = ts_language_version (ts_language); @@ -760,6 +777,28 @@ DEFUN ("treesit-language-abi-version", Ftreesit_language_abi_version, } } +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location, + Streesit_grammar_location, + 1, 1, 0, + doc: /* Return the path to the grammar file for LANGUAGE. + +If LANGUAGE isn't loaded yet, load it first. If the langauge can't be +loaded or the path couldn't be found, return nil. */) + (Lisp_Object language) +{ + CHECK_SYMBOL (language); + + Lisp_Object signal_symbol = Qnil; + Lisp_Object signal_data = Qnil; + struct treesit_loaded_lang lang + = treesit_load_language (language, &signal_symbol, &signal_data); + + if (!lang.lang || !lang.filename) return Qnil; + + return DECODE_FILE (make_unibyte_string (lang.filename, + strlen (lang.filename))); +} + \f /*** Parsing functions */ @@ -1305,8 +1344,9 @@ treesit_ensure_query_compiled (Lisp_Object query, Lisp_Object *signal_symbol, Lisp_Object language = XTS_COMPILED_QUERY (query)->language; /* This is the main reason why we compile query lazily: to avoid loading languages early. */ - TSLanguage *treesit_lang = treesit_load_language (language, signal_symbol, - signal_data); + struct treesit_loaded_lang lang + = treesit_load_language (language, signal_symbol, signal_data); + TSLanguage *treesit_lang = lang.lang; if (treesit_lang == NULL) return NULL; @@ -1477,8 +1517,9 @@ DEFUN ("treesit-parser-create", Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; TSParser *parser = ts_parser_new (); - TSLanguage *lang = treesit_load_language (language, &signal_symbol, - &signal_data); + struct treesit_loaded_lang loaded_lang + = treesit_load_language (language, &signal_symbol, &signal_data); + TSLanguage *lang = loaded_lang.lang; if (lang == NULL) xsignal (signal_symbol, signal_data); /* We check language version when loading a language, so this should @@ -4275,6 +4316,7 @@ cons (REGEXP . FN), which is a combination of a regexp and a predicate defsubr (&Streesit_language_available_p); defsubr (&Streesit_library_abi_version); defsubr (&Streesit_language_abi_version); + defsubr (&Streesit_grammar_location); defsubr (&Streesit_parser_p); defsubr (&Streesit_node_p); -- 2.39.5 (Apple Git-151) ^ permalink raw reply related [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-29 4:54 ` Yuan Fu @ 2024-08-29 6:01 ` Eli Zaretskii 2024-09-11 5:09 ` Yuan Fu 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-08-29 6:01 UTC (permalink / raw) To: Yuan Fu; +Cc: 64830, acm, stefankangas > From: Yuan Fu <casouri@gmail.com> > Date: Wed, 28 Aug 2024 21:54:26 -0700 > Cc: Stefan Kangas <stefankangas@gmail.com>, > Alan Mackenzie <acm@muc.de>, > 64830@debbugs.gnu.org > > Ah, thanks for the review! TIL. Here’s the revised patch. A few more nits: > + const char *sym; > + dynlib_addr((void (*) (void)) langfn, &loaded_lang.filename, &sym); ^^ We leave one space between the function name and the opening paren. Also, do you really need the type-cast for langfn? Do you get compiler warnings if you remove the cast? > +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location, > + Streesit_grammar_location, > + 1, 1, 0, > + doc: /* Return the path to the grammar file for LANGUAGE. ^^^^ "Path" again. I suggest "absolute file name" instead. > +If LANGUAGE isn't loaded yet, load it first. If the langauge can't be > +loaded or the path couldn't be found, return nil. */) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I suggest "or the file name couldn't be determined". Thanks. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-29 6:01 ` Eli Zaretskii @ 2024-09-11 5:09 ` Yuan Fu 2024-09-11 12:09 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Yuan Fu @ 2024-09-11 5:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830, acm, stefankangas [-- Attachment #1: Type: text/plain, Size: 1917 bytes --] Finally able to address this again. > On Aug 28, 2024, at 11:01 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Yuan Fu <casouri@gmail.com> >> Date: Wed, 28 Aug 2024 21:54:26 -0700 >> Cc: Stefan Kangas <stefankangas@gmail.com>, >> Alan Mackenzie <acm@muc.de>, >> 64830@debbugs.gnu.org >> >> Ah, thanks for the review! TIL. Here’s the revised patch. > > A few more nits: > >> + const char *sym; >> + dynlib_addr((void (*) (void)) langfn, &loaded_lang.filename, &sym); > ^^ > We leave one space between the function name and the opening paren. > Also, do you really need the type-cast for langfn? Do you get > compiler warnings if you remove the cast? Oops. And yeah, I actually get an error: treesit.c:702:16: error: incompatible function pointer types passing 'TSLanguage *(*)(void)' (aka 'struct TSLanguage *(*)(void)') to parameter of type 'void (*)(void)' [-Wincompatible-function-pointer-types] 702 | dynlib_addr (langfn, &loaded_lang.filename, &sym); | ^~~~~~ ./dynlib.h:39:26: note: passing argument to parameter 'ptr' here 39 | void dynlib_addr (void (*ptr) (void), const char **file, const char **sym); | ^ The error seems reasonable to me, I just don’t know other way to suppress it. >> +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location, >> + Streesit_grammar_location, >> + 1, 1, 0, >> + doc: /* Return the path to the grammar file for LANGUAGE. > ^^^^ > "Path" again. I suggest "absolute file name" instead. > >> +If LANGUAGE isn't loaded yet, load it first. If the langauge can't be >> +loaded or the path couldn't be found, return nil. */) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I suggest "or the file name couldn't be determined”. Done. Please take a look at the latest patch, thanks! Yuan [-- Attachment #2: grammar-location.patch --] [-- Type: application/octet-stream, Size: 6704 bytes --] From 5158271bf6ef6d6c28d88fe21acd85169e10e93b Mon Sep 17 00:00:00 2001 From: Yuan Fu <casouri@gmail.com> Date: Tue, 27 Aug 2024 22:31:42 -0700 Subject: [PATCH] Add Ftreesit_grammar_location * src/treesit.c (treesit_loaded_lang): New struct. (treesit_load_language): Return a struct instead of just the language object. The struct contains both the language object and the path to the shared library. (Ftreesit_language_available_p, Ftreesit_language_abi_version) (treesit_ensure_query_compiled, Ftreesit_parser_create): Update call of treesit_load_language. (Ftreesit_grammar_location): New function. --- src/treesit.c | 68 +++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 55 insertions(+), 13 deletions(-) diff --git a/src/treesit.c b/src/treesit.c index 5aedca44489..f2adf92d8c6 100644 --- a/src/treesit.c +++ b/src/treesit.c @@ -22,6 +22,7 @@ Copyright (C) 2021-2024 Free Software Foundation, Inc. #include <config.h> #include "lisp.h" #include "buffer.h" +#include "coding.h" #include "treesit.h" @@ -491,6 +492,14 @@ treesit_initialize (void) \f /*** Loading language library */ +struct treesit_loaded_lang +{ + /* The language object. */ + TSLanguage *lang; + /* The path to the shared library. */ + const char *filename; +}; + /* Translate a symbol treesit-<lang> to a C name treesit_<lang>. */ static void treesit_symbol_to_c_name (char *symbol_name) @@ -575,7 +584,7 @@ treesit_load_language_push_for_each_suffix (Lisp_Object lib_base_name, If error occurs, return NULL and fill SIGNAL_SYMBOL and SIGNAL_DATA with values suitable for xsignal. */ -static TSLanguage * +static struct treesit_loaded_lang treesit_load_language (Lisp_Object language_symbol, Lisp_Object *signal_symbol, Lisp_Object *signal_data) { @@ -626,6 +635,7 @@ treesit_load_language (Lisp_Object language_symbol, dynlib_handle_ptr handle; const char *error; Lisp_Object error_list = Qnil; + struct treesit_loaded_lang loaded_lang = { NULL, NULL }; tail = path_candidates; error = NULL; @@ -650,7 +660,7 @@ treesit_load_language (Lisp_Object language_symbol, mismatch. */ *signal_symbol = Qtreesit_load_language_error; *signal_data = Fcons (Qnot_found, Fnreverse (error_list)); - return NULL; + return loaded_lang; } /* Load TSLanguage. */ @@ -672,7 +682,7 @@ treesit_load_language (Lisp_Object language_symbol, { *signal_symbol = Qtreesit_load_language_error; *signal_data = list2 (Qsymbol_error, build_string (error)); - return NULL; + return loaded_lang; } TSLanguage *lang = (*langfn) (); @@ -685,9 +695,14 @@ treesit_load_language (Lisp_Object language_symbol, *signal_symbol = Qtreesit_load_language_error; *signal_data = list2 (Qversion_mismatch, make_fixnum (ts_language_version (lang))); - return NULL; + return loaded_lang; } - return lang; + + const char *sym; + dynlib_addr ((void (*) void) langfn, &loaded_lang.filename, &sym); + + loaded_lang.lang = lang; + return loaded_lang; } DEFUN ("treesit-language-available-p", Ftreesit_language_available_p, @@ -704,7 +719,9 @@ DEFUN ("treesit-language-available-p", Ftreesit_language_available_p, treesit_initialize (); Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; - if (treesit_load_language (language, &signal_symbol, &signal_data) == NULL) + struct treesit_loaded_lang loaded_lang + = treesit_load_language (language, &signal_symbol, &signal_data); + if (loaded_lang.lang == NULL) { if (NILP (detail)) return Qnil; @@ -750,9 +767,9 @@ DEFUN ("treesit-language-abi-version", Ftreesit_language_abi_version, { Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; - TSLanguage *ts_language = treesit_load_language (language, - &signal_symbol, - &signal_data); + struct treesit_loaded_lang lang + = treesit_load_language (language, &signal_symbol, &signal_data); + TSLanguage *ts_language = lang.lang; if (ts_language == NULL) return Qnil; uint32_t version = ts_language_version (ts_language); @@ -760,6 +777,28 @@ DEFUN ("treesit-language-abi-version", Ftreesit_language_abi_version, } } +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location, + Streesit_grammar_location, + 1, 1, 0, + doc: /* Return the absolute file name of the grammar file for LANGUAGE. + +If LANGUAGE isn't loaded yet, load it first. If the langauge can't be +loaded or the file name couldn't be determined, return nil. */) + (Lisp_Object language) +{ + CHECK_SYMBOL (language); + + Lisp_Object signal_symbol = Qnil; + Lisp_Object signal_data = Qnil; + struct treesit_loaded_lang lang + = treesit_load_language (language, &signal_symbol, &signal_data); + + if (!lang.lang || !lang.filename) return Qnil; + + return DECODE_FILE (make_unibyte_string (lang.filename, + strlen (lang.filename))); +} + \f /*** Parsing functions */ @@ -1305,8 +1344,9 @@ treesit_ensure_query_compiled (Lisp_Object query, Lisp_Object *signal_symbol, Lisp_Object language = XTS_COMPILED_QUERY (query)->language; /* This is the main reason why we compile query lazily: to avoid loading languages early. */ - TSLanguage *treesit_lang = treesit_load_language (language, signal_symbol, - signal_data); + struct treesit_loaded_lang lang + = treesit_load_language (language, signal_symbol, signal_data); + TSLanguage *treesit_lang = lang.lang; if (treesit_lang == NULL) return NULL; @@ -1477,8 +1517,9 @@ DEFUN ("treesit-parser-create", Lisp_Object signal_symbol = Qnil; Lisp_Object signal_data = Qnil; TSParser *parser = ts_parser_new (); - TSLanguage *lang = treesit_load_language (language, &signal_symbol, - &signal_data); + struct treesit_loaded_lang loaded_lang + = treesit_load_language (language, &signal_symbol, &signal_data); + TSLanguage *lang = loaded_lang.lang; if (lang == NULL) xsignal (signal_symbol, signal_data); /* We check language version when loading a language, so this should @@ -4275,6 +4316,7 @@ cons (REGEXP . FN), which is a combination of a regexp and a predicate defsubr (&Streesit_language_available_p); defsubr (&Streesit_library_abi_version); defsubr (&Streesit_language_abi_version); + defsubr (&Streesit_grammar_location); defsubr (&Streesit_parser_p); defsubr (&Streesit_node_p); -- 2.39.5 (Apple Git-151) [-- Attachment #3: Type: text/plain, Size: 2 bytes --] ^ permalink raw reply related [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-09-11 5:09 ` Yuan Fu @ 2024-09-11 12:09 ` Eli Zaretskii 2024-09-12 8:06 ` Yuan Fu 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2024-09-11 12:09 UTC (permalink / raw) To: Yuan Fu; +Cc: 64830, acm, stefankangas > From: Yuan Fu <casouri@gmail.com> > Date: Tue, 10 Sep 2024 22:09:04 -0700 > Cc: stefankangas@gmail.com, > acm@muc.de, > 64830@debbugs.gnu.org > > Done. Please take a look at the latest patch, thanks! LGTM, but... > +struct treesit_loaded_lang > +{ > + /* The language object. */ > + TSLanguage *lang; > + /* The path to the shared library. */ > + const char *filename; > +}; > + ..."path" again. > +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location, > + Streesit_grammar_location, > + 1, 1, 0, > + doc: /* Return the absolute file name of the grammar file for LANGUAGE. > + > +If LANGUAGE isn't loaded yet, load it first. If the langauge can't be ^^^^^^^^ A typo. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-09-11 12:09 ` Eli Zaretskii @ 2024-09-12 8:06 ` Yuan Fu 0 siblings, 0 replies; 33+ messages in thread From: Yuan Fu @ 2024-09-12 8:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 64830-done, Alan Mackenzie, Stefan Kangas > On Sep 11, 2024, at 5:09 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Yuan Fu <casouri@gmail.com> >> Date: Tue, 10 Sep 2024 22:09:04 -0700 >> Cc: stefankangas@gmail.com, >> acm@muc.de, >> 64830@debbugs.gnu.org >> >> Done. Please take a look at the latest patch, thanks! > > LGTM, but... > >> +struct treesit_loaded_lang >> +{ >> + /* The language object. */ >> + TSLanguage *lang; >> + /* The path to the shared library. */ >> + const char *filename; >> +}; >> + > > ..."path" again. > >> +DEFUN ("treesit-grammar-location", Ftreesit_grammar_location, >> + Streesit_grammar_location, >> + 1, 1, 0, >> + doc: /* Return the absolute file name of the grammar file for LANGUAGE. >> + >> +If LANGUAGE isn't loaded yet, load it first. If the langauge can't be > ^^^^^^^^ > A typo. Oops (^^;) That’s embarrassing. Ok, I fixed everything and pushed to master. Also, since the original problem is fixed, closing this report. Yuan ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-26 19:50 ` Alan Mackenzie 2024-08-26 22:25 ` Stefan Kangas @ 2024-08-27 12:01 ` Eli Zaretskii 1 sibling, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2024-08-27 12:01 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 64830, casouri > Date: Mon, 26 Aug 2024 19:50:43 +0000 > Cc: casouri@gmail.com, 64830@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > > We support grammar libraries in ~/.emacs.d/tree-sitter so that users > > could easily install versions of grammar libraries different from what > > their sysadmins decide to install. > > Ah, OK. Seems like a good reason. > > How about outputting a message looking something like this: > > Loading /home/acm/.emacs.d/tree-sitter/libtree-sitter.so ....Done > > .. This wouldn't get in the way, yet might well prevent some of the > problems I've been having over the last few days. As a diagnostic tool, by default off, maybe. Annoying everyone with this message, when it will almost always be redundant, doesn't sound like TRT to me. And note that in the usual case, when the grammar library is loaded from a system-wide directory of shared libraries, Emacs doesn't even know the absolute file name of the library, just its base name. ^ permalink raw reply [flat|nested] 33+ messages in thread
* bug#64830: 30.0.50 C++ treesitter mode no coloration 2024-08-26 17:25 ` Alan Mackenzie 2024-08-26 17:51 ` Eli Zaretskii @ 2024-08-27 11:03 ` Eli Zaretskii 1 sibling, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2024-08-27 11:03 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 64830, casouri > Date: Mon, 26 Aug 2024 17:25:34 +0000 > Cc: Eli Zaretskii <eliz@gnu.org>, 64830@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > Might it be worthwhile adding some functionality to Emacs whereby a user > could check which versions of grammar libraries she's got? Or is there > something like that already? Many (most?) grammar libraries don't have versions and don't make releases, so this would be tricky to implement. ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2024-09-12 8:06 UTC | newest] Thread overview: 33+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-07-24 9:13 bug#64830: 29.1; C++ treesitter mode no coloration David Come 2023-07-24 12:32 ` Eli Zaretskii 2024-08-14 17:35 ` bug#64830: 30.0.50 " Alan Mackenzie 2024-08-15 5:25 ` Eli Zaretskii 2024-08-16 16:44 ` Alan Mackenzie 2024-08-16 17:40 ` Eli Zaretskii 2024-08-16 17:45 ` Eli Zaretskii 2024-08-16 18:06 ` Alan Mackenzie 2024-08-16 18:27 ` Eli Zaretskii 2024-08-20 3:46 ` Yuan Fu 2024-08-24 18:35 ` Yuan Fu 2024-08-24 19:38 ` Alan Mackenzie 2024-08-24 20:43 ` Yuan Fu 2024-08-25 2:19 ` Alan Mackenzie 2024-08-25 4:54 ` Eli Zaretskii 2024-08-25 12:08 ` Alan Mackenzie 2024-08-25 12:17 ` Eli Zaretskii 2024-08-25 22:40 ` Yuan Fu 2024-08-26 17:25 ` Alan Mackenzie 2024-08-26 17:51 ` Eli Zaretskii 2024-08-26 19:50 ` Alan Mackenzie 2024-08-26 22:25 ` Stefan Kangas 2024-08-27 1:58 ` Yuan Fu 2024-08-27 12:09 ` Eli Zaretskii 2024-08-28 5:36 ` Yuan Fu 2024-08-28 12:33 ` Eli Zaretskii 2024-08-29 4:54 ` Yuan Fu 2024-08-29 6:01 ` Eli Zaretskii 2024-09-11 5:09 ` Yuan Fu 2024-09-11 12:09 ` Eli Zaretskii 2024-09-12 8:06 ` Yuan Fu 2024-08-27 12:01 ` Eli Zaretskii 2024-08-27 11:03 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.