打扰一下，请问 treesitter 开发的怎么样了？能否透露一下进展？我看到论坛里好像有人正在为 Emacs 开发 treesitter 或许你们两人可以合作一下。
也可能和工作环境有关系，我都是ssh到服务器，没有感受到GUI所带来的惊艳。但再怎么惊艳也顶多是一个浏览器而已呀。看看neovim，集成了treesitter、lsp，我能从它身上看到编辑器的将来，我没能从emacs这里看到。
好像正在等待 tree-sitter 的开发者解决一些关于 malloc 的问题
1 个赞
eglot 不是东西？
好的，谢谢…
其实我主要是想问他，因为他之前一直埋怨 Emacs 这边没有 treesitter，他自己要开发，还要找人合作，但我看到有两个第三方的 treesitter，一个活跃，一个废弃，看到他并没有参与，最近论坛里也有一位为 Emacs 开发了内置的，也没有看到他去帮忙，所以好奇的问一下。
neovim multi-tty 和同时开启多个系统窗口这些基本功能都做不到，就别谈编辑器的未来了，gedit 都不如
谢谢啊，居然有人惦记我，受宠若惊了。
最近在尝试用lsp作为笔记后端，想着用openresty在脱离编辑器的时候还能继续查文档，也想着用neo4j来建立笔记之间的联系。
treesitter我直接用了neovim的。
歪楼了，请楼下继续楼主的问题讨论。
我认为最基本的功能是生成ast。
我现在也是ssh+emacs, 对gui不是很在意了, neovim没有包袱, 而且不集成gui, 确实能稳步快跑.
话说, 我前几天尝试了下emacs daemon, 在服务器上启动emacs server, 然后每次ssh过去运行emacsclient来打开emacs, 发现有不少功能错乱, 包括lsp和company补全, lsp补全内容不正确, 而company提交补全项的时候, 会插入乱七八糟的内容. 最后也没解决, 放弃了.
用emacsclient很方便的一点是, 每次ssh过去, 可以瞬间打开emacs, 而且之前的会话都在, 跟tmux类似, 可惜好多功能工作不正常.
想生成 AST 可以用 Semantic，也可以用现有的 tree sitter 动态模块，不过我认为现有的语法分析（特别是 CC Mode 中的）已经足够满足我的需求。
您的观点是emacs的问题在于缺少全局的良好设计，导致计算会卡UI，导致没有好的跨平台图形API，导致多线程高性能编程很困难，您同时认为Emacs的生态很棒，Emacs社区几十年积累下来而的优秀插件不能丢，但您提出的解决方案是EAF，那些插件也不能比较容易地迁移到EAF，只能继续忍受没有好用的多线程基础设施和跨平台图形API，这不还是丢了生态吗？您指明的emacs的问题不都在那里，一个都没解决吗？难道要所有优秀的包都要用EAF重写一下，这工作量是不是还不如把emacs底层重新打磨好一点？
显然不是说有了EAF以后所有Emacs用户强制使用EAF，不需要相关功能的完全可以选择不用。我就对这些功能没有啥兴趣，EAF做的不好也和我没关系。至于自己想法一堆，自己做不出来，对别人给的方案也无法满意，那是另一回事。
6 个赞
你换个角度想：有了EAF，Emacs + EAF既可以继续使用Emacs原有的优秀插件，对于需要复杂UI或者大量计算的可以利用EAF，两全其美了，是吧？
懂了，我这种纯小白纯用户不应该评价别人技术方案的优劣。
不是所有的优秀插件都需要迁移到EAF。
绝大部分插件都在Emacs的当前设计下已经够好用了，这些插件接着用就行，根本不需要涉及EAF多线程和跨平台图形API。但有些个别新插件已经在挑战Emacs的性能极限了，比如LSP，比如网页和PDF渲染，又比如视频播放。这些功能与其花费大量时间精力口水战想方设法对Emacs本身的设计进行改革，不如另辟蹊径用EAF外包给最适合且本身就有足够优秀的多线程运算多媒体渲染能力的程序（QtWebEngine，PyMuPDF，NodeJS），而Elisp只需要接收运算结果并与Emacs生态的其他Elisp程序进行协调就行了。（并没有说前者想办法提升Emacs底层性能不好的意思，Po Lu做的事情非常好，但每个人的时间是有限的，我们更愿意花在自认为更有效率的刀刃上）
5 个赞
其实我也没觉得高级，使用场景我觉得是不少，比如我最近在手机上以web的方式 使用org-mode，其中手机端emacs配置文件太难写(没必要用和电脑端一样的配置)，我是全在电脑上写手机端termux里emacs的配置文件，这时电脑就是服务器了，返回elisp代码的内网地址类似为：`//192.168.2.10/home/.emacs.d/init/init-termux.el
手机端emacs启动后加载这个网络配置文件，这样免去在手机上写代码输入不方便的问题，但这么做的人估计不多
从生态角度来说，最合适的扩展语言当然是(Java|Type)Script；但从个人喜好出发，其实Ruby说不定更合适：语法更平易近人、有模块系统和面向对象、带有Lisp的很多痕迹（symbol，甚至call/cc都有）
另外我不了解Emacs GUI是怎么做渲染的。如果在主要的操作系统上直接用系统TextView渲染文字，会不会省很多工夫？或者说如果系统TextView API太上层，很多东西无法实现，那像楼上说的，用新理念的图形库会好很多？不过FSF不会接受，并且也相当于推倒重来，工作量太大
远程开发的话，不谈多人协作，其实只要把一部分command改成可以远程执行，很多主要问题就已经解决了
使用系统 TextView 限制太多，比如说 GtkTextView/GtkSourceView 很难做到 glyphless-char-display 或 word-wrap-by-category 这一类的功能，更不要指望用 GTK 实现 bidi-find-overridden-directionality 等地层功能。
再说，Emacs 难道没有使用新概念的图形库吗（X11 平台上使用 Cairo，macOS 使用 Core Graphics，只有 MS-Windows 上比较落后，使用 GDI）？改变外部使用的各种库没有什么用处，最多达到表面上的安慰剂作用。
如果想推倒重来，可以先去了解一下 xdisp.c，dispnew.c，composite.c，bidi.c，xfaces.c 提供的各种功能，再把那些功能复制出来。
call/cc 实战中基本没啥用,图一乐功能
The experience with call/cc in other languages has led to similar doubts, if not opposition. Koichi Sasada, a developer of the Ruby interpreter and the developer of the Ruby Virtual machine, summarized his Continuation Fest 2008 talk about call/cc in Ruby thusly:
Ruby's Full-Continuation Considered Harmful
Produce many many bugs
Nobody use `callcc' method except experimental code
Ruby 1.9 or later solves this issue with kick out `callcc' feature to Library
Ruby 2.0 includes this library?
His talk painfully details the pain inflicted by call/cc on the language developers and demonstrates, among other things, that implementing threads with call/cc works really bad in practice.
这还是 Ruby 开发者说的
我赞同把图形和耗时操作剥离出来，其他的维持现状可能是目前最好的方式。
1 个赞