tree-sitter highlighting rocks

This is a soft nudge to those who haven't yet installed `tree-sitter`. I had to inspect a 27MB json-file, about 1500000 lines, pretty-printed. Emacs warned about a _really huge_ file, opened quickly nonetheless. Changing text at the bottom was extremely sluggish. Disabling font-lock-mode made Emacs instantaneous. After installing tree-sitter and enabling `tree-sitter-hl-mode` the edit experience is fantastic. Editing this large json file, Emacs is still slightly laggy but it is light-years better than with the regexp-based font-locking. Also tried tree-sitter while editing golang, no issues whatsoever. If you haven't installed tree-sitter yet, you should.

Is anyone using `tree-sitter` for daily-driver C/C++ work? I'm sure tree-sitter is interesting and technically great, I just have a fairly strong bias against experimental stuff for day to day development.

[deleted]

Yes, using it for at least half a year now without any issues for daily work. Makes working with large, multi thousand lines files very noticeably faster and did not cause any issues yet.

Does tree-sitter depend on platform/processor/architecture-specific blobs? (Its GH page mentions modules).

I tried it once lately and it made emacs hang often while navigating the buffer. The hangs did not happen when tree-sitter was disabled. Is it truly good for daily use?

I switch to tree sitter for some unit test files for the same reason: lag. Works great but I'm not used to the way it highlights syntax, so I haven't switched full-time.

I use it for editing rust, python and typescript code daily; the quick fontification is really nice, and so is the absence of the font-lock problem I’ve started calling “stuck string”, where a string in the middle of the file is not registered as terminated (causing the remainder of the file to look like it’s part of the string). All that, plus combobulate for syntax-based navigation. Tree-sitter is good stuff.

No. The code generated by tree-sitter is cross-platform, dependency-free C.

I’ve been using it for at least a year and haven’t had a problem with it. I’m sorry it didn’t work out for you; if you can still reproduce it, I’m sure the emacs-tree-sitter folk would appreciate a bug report.

Thanks.

Yeah, I guess I would need to dig deeper to find what is causing this hanging if this is only happening to me.

Hmm .. I have the opposite experience. Using tree sitter in my cpp codebase makes scrolling sluggish, I had to disable it.

TIL https://github.com/mickeynp/combobulate Thank you, @snafuchs !

I noticed hanging for big files, but only when I was modifying them/saving them. That makes sense because tree-sitter has to rebuild parts of the syntax tree on the fly

The emacs tree-sitter packages (tree-sitter/tree-sitter-langs, tree-sitter-hl, tree-sitter-indent) also make it an absolute breeze to write your own language major modes without all the normal regex hassles. I leaned on it very heavily in [https://github.com/anticomputer/emacs-codeql/blob/main/ql-tree-sitter.el](https://github.com/anticomputer/emacs-codeql/blob/main/ql-tree-sitter.el) and it's great how much simpler fixing indentation and highlighting issues becomes with the structural approach.

Which C++ version, though? This is one thing I that stops me from playing with tree-sitter: I can't gauge the state of the grammars they use. For C++, which version is it, and how complete the support is? Can it handle C++17 with all its peculiarities? What about C++20? And if it breaks, how bad is it? I tried to look at the C++ grammar repo, but there's nothing there that would give an indication of how correct or up-to-date the grammar is.

Related bugs: https://github.com/emacs-tree-sitter/elisp-tree-sitter/issues/204 Also, using `tree-sitter` with Rustic causes noticeable slowness, but with Python is fine.

This is to be expected. My experience: If you disable font-locking, emacs without tree-sitter is the fastest. If you would like to use font-locking, tree sitter powered font-locking is much faster

The documentation says they rely on the faces font-locking defines added with faces font-locking cant provide as regexp-based font-locking doesn't have that much structural information. If you don't like the appearance it is likely the overshot with the decorations.

Mostly 14 and 17. 17 seems to be covered reasonably well but haven't checked specific edge cases. Cannot say anything on 20 support. But it is very easy to install, maybe give it a try and report back what you found

you work with embedded devices to have this concern?

Do Raspberry Pis count?

> An embedded system describes a microprocessor-controlled computer hardware system that runs dedicated software to perform a specific task. i guess no

Obviously not, but you see the validity of my initial concern, right? And that raising embedded systems as if they were the only possible site of occurence is simply wrong.

Just started giving this a try based on reading https://emacs-tree-sitter.github.io/installation/ -- ended up with this configuration: ``` (use-package tree-sitter-langs :ensure t) (use-package tree-sitter :ensure t :after tree-sitter-langs :config (global-tree-sitter-mode) (add-hook 'tree-sitter-after-on-hook #'tree-sitter-hl-mode)) ``` i am curious if i need to disable this, however, in order to get the real/maximum benefits? ``` (global-font-lock-mode t) (setq font-lock-maximum-decoration t) ``` according to the syntax highlighting section, the hl-mode overrides font-lock so maybe it is not necessary to disable?