挺奇怪的……
鉴于Emacs开发者倾向多用Lisp少用C（降低维护难度、对新人友好），这个不难理解。
大概写elisp的也不会研究这么core的东西，做编译器的人直接上手更高级的理论，只有我这种闲人才有心思看。
顺带补充了下4个文件是干嘛的
又有大更新：
Another update on gccemacs, this time quite substantial.
It brings in support for: garbage collector, image dump and bootstrap plus some more.
作者nb（虽然我还没试过
现在又开始活跃讨论了，而且准备推上emacs开发仓库。
https://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/native-comp
1 个赞
昨天已经在win10机器上编译分支 native-comp成功，今天晚上回去看看运行情况。
3 个赞
一定要分享下使用效果啊
libgccjit用msys2-and-mingw64编译有问题，春节看看啥原因，不知道能否解决？ 最近关注 emacs-devel 邮件，感觉到中国为啥没有 像gnu 的开源组织，感觉大牛人都在国外。
gnu有一个就够了呀。再说emacs-devel上面不乏中国人的影子。 相比国外的话国内emacs更加小众，大概是因为大量的参考资料包括emacs lisp manual都是英文写的，首先在语言关就能筛掉好多人呢。
印象最深刻的是一个叫VanL的人，签名可以说是很魔性了（如下）
əə0@ 7 6 4 5 bit byte word 6502 memory map dma ssd intelligence io 🐞
一 二 三 言 語 𝔖 吳天夫大家 园 元 示 証明 白 記号意味 自己海外國漢本華人
Stardict 还真用过，挺不错的软件…… 这是走火入魔了啊
突然想明白，为什么emacs开发社区对通过libgccjit来加速elisp执行速度提不起兴趣：
- elisp 太老了，30多年前开发的，不是正真编程语言。如果还是在elisp 基础上进行修修改改，解决不了根源问题，不如把elisp替换掉。
- emacs社区都形成共识，替换elisp迟早事情。
- 对于用Guile替换elisp，Richard Stallman支持Guile替换elisp ，Guile也很有潜力。
但目前最大问题是缺乏用Guile替换elisp计划表，对emacs维护者是一个很大挑战，也需要很大的勇气。
以上都是个人想法，请指教。
参考：
1 个赞
好奇一个问题，教主现在对emacs还有多少影响力？
1 个赞
有点云评论家的感觉了。
什么是根源问题？
Guile Emacs已经死透了。换语言意味着40年的生态推倒重来，那真就可以直接去用VSCode了。
没说过，只是觉得Emacs如果能支持用Scheme写extension也是极好的。
你有看过emacs-devel上的讨论吗？
从11月到1月都是一大串连续讨论，不知道什么叫提不起兴趣。
对libgccjit没有兴趣，对guile就有兴趣？凭啥？凭你是Scheme？我寻思Emacs的maintainer比Guile的maintainer还勤快呢。
打打嘴炮是很容易的，把嘴炮落到实处那就是另外一回事了。另外，cairo rendering从Emacs 25就开始做，等几年后的Emacs 27才彻底完工，这个计划不过是刚开始几个月而已，泼冷水也为时尚早了。
8 个赞
说到底Emacs对elisp的性能提升不是很感冒的原因就是Emacs本质上还是个编辑器，要功能不要性能。不期望Elisp做高强度的运算工作，就算要做，也可以用C写成dynamic module给Elisp调用。不然像Python慢如蜗牛还有GIL（这个Elisp也有），何德何能能占据科学计算领域的大头？
4 个赞
对Emacs来说生态和可维护性最重要。速度很好但不能影响到这两方面。
就是一个打打酱油的人，偶尔也会写点代码，经常出来强调政治风向（甚至遇到不懂的东西会闹出笑话）
https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00210.html
还有有人吵起来的时候出来强调一下和谐友爱
Emacs本质上还是个编辑器，要功能不要性能，这都点不认同。追求更快更好emacs，和将emacs变成全能玩具（live in emacs），至少本人对emacs有这个期望。
你可以学学dynamic module 