这个问题有点印象, 是不是简单的宏没问题? 复杂的才有问题?
这个应该能配置, tree-sitter这种方案应该是大趋势
看上去treesitter更准确, 比如下面的pid变量也识别了,
但是printf里面的pid变量没识别…
python-ts-mode 是怎么产生的？
是的 不过不是很在意语法高亮 (因为有symbol-overlay).主要是切换时会有卡顿. 所以暂时都是不打开 c-ts-mode.
2 个赞
Emacs 29 以上编译时支持 tree-sitter 的话就内置了啊。
这个感受 不明显，我是用的lsp和flycheck
tree-sitter 现在是没法和 eglot 配合使用么？
当我打开cpp文件，切换到 c++-ts-mode, 发现eglot 没有启用，使用M-x eglot 显式启用eglot, 发现eglot会报错:
[eglot] Sorry, couldn't guess for `c++-ts-mode`
eglot 版本太低了吧，新版本的 eglot-server-programs 都是包含 *-ts-mode 的
1 个赞
感谢哈 
eglot 需要根据 major mode 打开对应的 lsp server，c+±mode 改成 c+±ts-mode 了，不认识，得配置一下 eglot 的 major mode 也 lsp server 的关系
我直接把 elpa/eglot 删除掉，直接使用 emacs-29 内置的eglot 就好.
速度我还没感受，但准确性我看是提高了，高亮效果更好了:
这是普通的 c+±mode。 这是 treesitter c+±ts-mode，可以看到原本函数内调用的函数名没有高亮，现在都有高亮了，而且类名也有高亮，变量也都有了高亮。原来很多没有颜色的，现在都有了颜色，这差别还是挺明显的。
这是在写什么解释器吗?
不是写，是看 
颜色不是越多越好你这个例子里面c++-mode的显示是符合作者的设计意图的。
- 名字空间不用type-face是因为它不是type
- 模板参数不用type-face是因为不一定是type
- 函数调用不用function-face是因为function-face是应该用在定义上而不是调用上的
相比之下c++-ts-mode的显示是不符合emacs的type-face的意图的。
可是 parse 作为一个变量，一开始有颜色，后面没有，这不就不一致了么
1 个赞
你理解了Emacs语法高亮的逻辑以后就不觉得不一致了。在写程序时，我更关注的是一个新变量/新函数的作用域从哪里开始，Emacs会把这个点用颜色高亮。至于使用变量/函数的点，高亮它们并没有什么用处，一个程序里除了运算符之外，不就全都是引用变量和函数吗？
1 个赞