应该是没问题的，cc-mode 的 tree-sitter 支持还在讨论中。
这也是为什么 Emacs 要引入 tree-sitter的主要原因。C# 和 TypeScript 在 Emacs 中都寄希望于 tree-sitter，原来的实现有些难以解决的问题。
Vim 倒是有个建议选用 TextMate regex 进行语法高亮的讨论很有趣。
主要抨击了 tree-sitter 的能耗高、缓冲区同步差、可靠性、parser 质量差。还有就是占用磁盘空间的问题等。
1 个赞
看来没有完美的万能方案。希望 Emacs 的 tree-sitter 不会让大家失望。
用texmate的方案确定不是开倒车吗。。。vscode的语法高亮我觉得平平无奇吧，并没有觉得很好。而且vscode就是因为语法高亮太乐色了，所以在lsp里加入了语义高亮协议。在某些语言（其实指的就是你c++），语义高亮确实能做的比treesitter这种语法级的高亮好，但是论性能消耗，lsp的性能消耗要比treesitter大到天上去了吧。至于绝大部分语言，语法高亮并不会比语义高亮差，而vscode因为默认的高亮太乐色了，还得靠lsp的语义高亮来补。。。这确定不是拆了东墙补西墙，甚至丢了西瓜捡芝麻？
你可以看下那个 issue 里的讨论，我 Vim Emacs 都是菜鸟，不过看的挺有意思的。
其中就有个人说了 tree-sitter 平均支持一种语法高亮就需要 500kb，支持500种文件格式就需要两百多兆，这对于 Emacs 来说可能不算什么，但 Vim 还只是个文本编辑器啊。（它只是个孩子啊，大雾
1 个赞
确实，vim的定位毕竟是操作系统/发行版标配编辑器，要在任何系统/环境上都要能够运行，很多事情都不太能放开手脚干。比如像neovim和emacs，就可以比较随意的分发二进制插件。treesitter确实在这里受到的限制太大了。而且treesitter在neovim上支持的比较好的语言也不是很多，反正和300个这个肯定没办法比。
Jerry
71
根据维基百科显示，目前世界上大概有700 种编程语言 （乐
现在 Vim 内置支持的文件格式有三百多种，500 也算是大差不差的范围。
更正：Vim 的 runtime/syntax 下面有 600+ 文件。
客观的说，我对tree-sitter的印象没那么好，第一太脆弱，第二其实很多语言的嵌套定位（比如parent node）并不准，导致一个函数要支持各种不同语言，各种hacking。
emacs原始的regx和sexp很原始，但是拧巴拧巴还很准确。
我开发了很久的 grammatical-edit ，效果并不好。
3 个赞
看来 tree-sitter 距离 1.0 版本发布任重道远啊 
我觉得这是因为目前各种语言的 tree sitter 实现还不完整，调教还不太行。
如果发现某个语言定位不准，不应该在 emacs 这边糊补丁，而是应该给对应的 tree sitter lang 做修改，让它给的结果本来就是准的。
emacs 内置的 tree sitter 是个 client，emacs 这边只要保证实现了协议的部分，能稳定，就 ok。
难的是每个具体的 lang parser 实现的质量，这个 emacs 管不了。
这东西和 lsp 很像，lsp client 好还不够，你得有对应的 server 支持才行
问题的关键就在于 tree-sitter 它不稳定啊。不然你以为我前面讨论的是啥……
再看看这个：
你发的那个 vim issue 9087 贴的 issue 截图几乎全是 lang 的问题
钻牛角尖就没意思了兄弟，那个网页提了136次 tree-sitter。
几乎任何软件都会有 bug，有 bug 修就是了
有横向对比 TextMate 的稳定情况么？TextMate 也只是一个规范，具体用什么实现？这个具体的实现稳定么？
据说也被应用在 VSCode 里，我还没考据。
BTW：你最好还是跟 Vim issue 里的大佬去讨论工程取舍问题，我只是个菜鸟用户，甚至都不是个程序员。我只知道 tree-sitter 现在没有发布 1.0 版本，至于为什么，我猜是怕挨骂吧。
其实这些都不重要，重要的是这个工具的发展方向。tree sitter 是真的去解析 AST 的，这决定了它的上限。要是觉得不稳定，再完善就好了。
要是为了稳定而降低上限，那就本末倒置了。
2 个赞