cc-mode是用elisp分析，这个是用rust分析，一个天上一个地下。
核心库是c吧，不是rust。即使这样，跟emacs27带的原生json库一样，可能会有其他开销，比如buffer内容拷贝等，编码转换等，导致最终效果一般。当然只是可能。
除了buffer内容拷贝之外，比如cc-mode的解析结果可以放在buffer内容的text property里，外部解析就很难这样，可能需要自己缓存。
你們嘴上都说要编辑器，身体都很诚实地要 IDE 啊
10 个赞
小孩子才做选择，成年人全都要。
话说语法树不是lsp能给出么，为什么还要搞这个？
你这政治取向不对，这叫做emacs特色的编辑器。。。。
3 个赞
一般直接调用 compiler 的，比如 lsp，需要完整合法的代码，每次檢查的开銷很大，做不到 incremental parsing 的 all at typing time。而且一遇到錯误就停止了，不能一次性列出所有问題。
你可以直接在这体驗一下。
3 个赞
vim可以有 vscode可以有 哪有神魔特色
不好意思，Vim 和 VSC 的 buffer 实現 (rope 和 piece table) 都说明了它们不能有。
求buffer实现的简明介绍或资料（或者说它们这些实现为什么不能有）
我觉得 tree-sitter的作者应该懂得 不能依赖某种buffer的实现
因为这些实現不能支持 emacs 用的那啥，marker。用來实現第三方 parse 的话 marker 挺重要的。
marker间移动是远远快于char pos间跳转么
VSC 这个是直接用 class advise 了 buffer impl。如果是 emacs 和 vim 这样不能修改 buffer impl 的还是不能实現。
并不，marker 说白了就是 char pos。然而 marker 相比直接用 integer 能自動在 buffer 接受输入后更新位置。当然你也可以自己实現 update 算法，当然不太可能比內建的快就是了。
1 个赞
代价就是marker多了影响性能
1 个赞
编辑器只要提供更新的文本和位置就行，具体实现应该没关系。而且tree-sitter允许你提供接口：“ The TSInput structure lets you to provide your own function for reading a chunk of text at a given byte offset and row/column position. The function can return text encoded in either UTF8 or UTF16. This interface allows you to efficiently parse text that is stored in your own data structure.”