现在是什么情况了,有人关注过吗?
看来 tree-sitter 快要合并到 Emacs 的 master 分支了,将会包含在预计明年春季发布的 Emacs 29.1 版本中。
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00707.html
太好了, 步入现代化
typescript-mode 也将加入 Emacs 29,并通过 Tree-sitter 实现。
因为 TypeScript 只是 JavaScript 的超集,typescript-mode 会直接加入到 ts-mode.el 中。
相关的邮件列表:
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00946.html
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00998.html
内置lsp和内置treesitter都是非常给力的变动,emacs距离现代化真的已经非常近了。对于emacs的新人用户来说,M-x eglot一开,再打开CUA模式,配合treesitter强大的高亮以及解析语法树带来的强大的文本编辑功能,基本上可以算得上是有一个零配置,开箱即用也能还算过得去的体验了。
期待 DAP 功能的内置,这样我的配置就可以去掉 60% 了
dap应该不太可能,主要是dap流行度远不如lsp呀,而且最常用的gdb emacs自带ui,根本不需要用dap。
dap 是 lsp 中调试代码的协议
据说tree-sitter占用的内存是buffer占用内存的10倍, 这个有点大, 打开几百个文件可能有压力
有人在 emacs-devel 提到了你这个担心:
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00966.html
Daniel Martín 在对 Emacs 29 的测试结果:
-
Emacs -Q
(macOS GUI app) 启动,大约占用 48 MB 的 RAM。 - 当
(require 'treesit)
时,内存使用量会攀升至大约 57 MB。如果打开一个大的 Python 文件, 并启用 Tree-sitter,对 Buffer 进行几次滚动后内存保持在 60-65 MB 左右。
他认为内存使用量会根据使用的方式而有所不同,但没有看到对内存使用有任何明显影响(没使用 tree-sitter 的 Emacs 相比)。
如果treezitter的支持很完善的话,开启treesit的高亮就直接把regex高亮给关掉,会不会把多占的内存省回来?现在neovim就已经支持只启用treesittee高亮,完全禁用regex了
同一个 Major mode 启用了 tree-sitter,原有的 regexp 高亮肯定是关闭的。但不是所有的 Major mode 都会支持 tree-sitter,不支持的还是会用 regexp 高亮。
内存应该不是问题了,现在内存不值钱。
要到这个程度,估计要等到 Emacs 30 了。现在也就是一些常用的 Major mode (第一个是 Python)支持 tree-siiter
tree-sitter现在的问题就是太脆弱了。改动一些特殊结构后整个文件都会挂掉。
希望 tree-sitter 合并到 Emacs 核心后在这方面会有所改善。
DAP 和 LSP 应该是分开的两个协议, 只是两个协议都是微软弄得, 底层通信机制是一样的。
DAP 我的理解本质还是统一不同调试器的协议封装, 希望可以给出统一的调试体验, DAP 本质是一个调试消息代理, 有点类似 lsp-bridge 一样, 在 Emacs 和各个调试器之间做了一个消息转发和VSCode的UI绘制。
只从调试的能力来说, DAP并没有增强各语言调试器的能力。
大佬能不能搞一个 dap-mode
平替,现在 dap-mode
出现问题已经半个多月了,打断点就崩溃,但是先前的版本是好的。
lsp-bridge耗费我今年好多精力,明年再说吧,社区项目不能一直这样投入,吃饭也很重要。
修改的位置后面部分挂掉可以理解, 前面部分也会挂掉?
内存应该是有优化空间的, 前期功能第一. 不知道能否处理目前最复杂的语言, 比如c++
还有就是容错性
regex高亮非常影响性能,在neovim里面,渲染长行的能力,regex和treesitter比简直是天壤之别。在emacs里用regex渲染org都时不时卡,非常无语。如果treesitter能够普及的话,emacs的使用流畅度估计又能大大上升。