Emacs维护者考虑加入incremental parsing功能

你是指哪方面的尝试?用tree sitter作parser么

有人提出了emacs自带的el版bison wisent,tree-sitter是不是要太监了。wisent 不能并行解析吧

好像有人已经开始用自带wisent parser的尝试了,不知道性能如何。

https://lists.gnu.org/archive/html/emacs-devel/2020-01/msg00634.html

Eli的想法大概是提供一个incremental parser,这样fontlock可以选择用RE,也可以选择用新的parser,jit lock这些逻辑不变,只是使用不同的底层工具。

这个parser当然也可以提供我之前说的那些功能,感觉很香。但是不知道为啥(emacs-devel里)讨论不是很活跃。大家都觉得现在的够用吗。

邮件列表好像又开始讨论了,不知道什么时候可以使用呢,感觉应该很不错。

看样子还在纠结是进emacs-devel 还是以模块的形式提供。 这东西就应该在进核心作为基础设施存在的

不要太乐观。

曾经有个 Emacs JIT Compiler,讨论到后来似乎就凉了 Emacs Lisp JIT Compiler

分支也好久没更新了,查了 commit 历史,没找到合并记录,应该是放弃了。

neovim已经有了 欢迎尝试

因为emacs-tree-sitter用的是Rust。emacs仓库目前只有C和Elisp,如果原封不懂拿进来是要增加额外维护成本的。

tree-sitter 需要用js生成特定语言的语义分析器,这样要进emacs就很麻烦,要么和tree-sitter维护者商量为emacs增加s表达式的形式,要么就只能自己改,直接用js生成的 so emacs-devel那帮人估计也不乐意依赖js

1 个赞

Rust扩展的程序,比如 Tree Sitter 和 fuz.el Python和JS扩展的程序,比如 EAF C扩展的程序,比如pyim和emacs-rime

建议都现在外部发展壮大后,有了很多用户后,再合并就比较顺畅。

初期合并,会花巨大的精力吵架,还不如多写代码靠实力说话。

2 个赞

一直不明白tree-sitter为什么要用Rust而不是C,只是做一个包装,并没有复杂的逻辑,Rust好像没有太大的好处,反而在Emacs Lisp和C的基础上又徒增一个语言。

好像是为了给 xi-editor 之类的用的。

看了下devel上几天来的讨论, 感觉讨论挺有必要, emacs开发者和tree-sitter开发者双方各自都在自己的领域有一些经验, 但是这两个领域可能不重合, 特别是emacs的历史上积攒了不少实践经验, 踩过不少坑, 有一些方案尝试过废弃了, 外行人可能都不知道, 可能会去再踩一遍.

总结一下争论的要点:

  1. 打开文件后是否进行一次全文解析然后增量解析? 还是一直仅部分解析?
  2. 如果tree-sitter做成外部模块, 如何让它访问buffer的文本数据? 直接访问emacs内部数据? 还是拷贝过去访问?

关于第一个:

tree-sitter进行全文解析会耗时比较长, 特别是大文件, 导致打开的时候用户要等待一会儿才能看到和编辑, 这个延时是个问题.

另外, tree-sitter全文解析后, 生成的解析树数据量是对应文件大小的8倍(比较夸张), 如果一直保存, 消耗内存相当大. 如果不保存, 好像又浪费了, 而且后面又要重新全文解析.

如果一直仅局部解析, 又很难得到准确解析结果.

这个好像是很明确的事情, 不需要额外的代码来验证了, 就是摆在眼前的问题.

所以说像这些问题,其实应该可以先在外围自由发展,用户会用脚投票的。

当作者把这些问题都解决的差不多的时候,那时候在讨论进不进入,我觉得更为顺畅了。

因为项目还在初期阶段,又要增加额外语言的负担,所以这时候讨论必定会没什么结果。

我一直觉得插件在里面是emscs主分支和外围,在代码自由度上没什么区别,只是说在主分支传播力更广而已。

但是这个东西又不是个很独立的东西, 牵涉到emacs的核心和基础, 比如高亮, 缩进, imenu, 甚至符号跳转, 如果采用了, 可能会集成到emacs内部, 作为这些基础功能的通用部分(基础engine), 他们可以共享同一个语法树, 省下不少cpu和内存资源. 而且它的数据还可以跟内部的text property共享, 也会节省一些资源. 如果能提供这么多功能, 那8倍内存消耗和打开的延时可以接受.

在外部独立发展的话, 体验不到这样的效果. 不像LSP那么独立.

完全扫描我看是很难避免的,分开扫描像比起来实现复杂太多,也更容易出错。

可供选择最好, 可以提供一个选项来控制. 比如有的人代码比较简单规范, 不会出现那种极端情况, 可以选择高性能. 其他人可以选择高准确性.

嗯,你说的很有道理。从基础设施来说,确实放主分支比较好。

1 个赞

我对imenu比较依赖, 而imenu是必须全文扫描的, 如果它支持imenu, 我肯定选择全文扫描.