上 melpa 的话题懒猫之前也说过了，一个是很多是有外部依赖的，上 melpa 多少有些麻烦，一个是带来额外的维护成本，他自己不用 melpa 安装插件。
这个帖子一下戾气太重，都不敢发离题的回复了。。。
标题是不用 Native Comp 反而流畅，然后使用几天发现 Magit 确实不如 Nativa Comp，然后我主动 at 了懒猫，问他有没有想法，甚至我还说了类似 lsp bridge 的外部程序的方式，这时候懒猫的回复我真的看不到一点离题的地方，甚至说是打广告都不应该，这就是我在找的东西
不同人看法不一样，我倒是觉得 magit 有性能问题，那拿出来一个完全替换的工具，像 lsp bridge 替换 lsp mode，也完全是符合题意的
一直感觉Native Comp是花了大代价解决了小问题, 不划算.
之前在magit的issue讨论里看到一个思路, 就是用rpc的方式来实现magit, 类似于lsp把耗时的工作交给外部lsp server. 想法挺不错, emacs可以内置一套rpc的机制, 方便把一些复杂功能放在外部实现.
对，这个思路已经在 lsp bridge 证明可行了，所以我上面才会这么问的，懒猫已经把 rpc 机制这块实现了， GitHub - manateelazycat/python-bridge: Write Emacs Plugin by Python, split code from EAF. 就是 Magit 的复杂度，实现起来估计成本有点高
1 个赞
同感，最近开了一个月时间 native-comp，还是决定不用了，不开 native-comp 对我来说已经够快了。
主要是作为一个c++程序员我是比较认可编译这个过程，而对python这种解释类型的语言比较嫌弃的，magit只是一个方面，emacs毕竟有大量elisp代码，能通过编译提升速度对我来说是完全能够接受的，我认为最理想的语言就是开发的时候可以使用解释器立马得到结果，又能在发布时通过编译提升速度