我和 @MatthewZMD 最近在复刻 Cursor
欢迎大家一起来加入开发。
这个项目的目标：
欢迎大家点赞github项目。
底层架构用的 python-bridge， 和EAF/lsp-bridge 类似， 利用Python的多线程和生态， Elisp/Python混合编程， 开发速度快， 永远永远都不会卡住Emacs。
考虑下 Go or Common Lisp？
nodejs 和 python 的依赖安装都很头大，太容易安装不上了，两者的解释器发版太快而且比较频繁引入不兼容。
我就不推荐 Rust 了。。。
另外，如能考虑下编辑器中立那就更妙了。。。。
python的llm生态最完善，现在还在早期开发阶段，等稳定下来用uv包装一下就好了，依赖好处理
开始写Emigo的想法可以在这里有详解：Aidermacs 2.0 Initiative: No More Aider, Only Emigo · MatthewZMD/aidermacs · Discussion #98 · GitHub
依赖uv来解决就好了。
编译器中立不考虑，没那个时间。
这个场景不是 LLM 训练也不是推理，就是一点 LLM HTTP API 调用，以及在这之上封装的一点所谓 agent framework，说白了就是个超级简陋的 workflow engine，看看这个： GitHub - The-Pocket/PocketFlow: Pocket Flow: 100-line LLM framework. Let Agents build Agents!
其实跟 Python 一点关系都没有，只是机器学习这圈子盛行 Python，另一个流行的选择是 JS，这也只是 JS 现在很流行而已，跟 LLM 没关系。
并不是很强烈的建议，你们延续 EAF 的成功经验也是个很合理的权衡。
保持关注！
点赞支持一波！
我注意到最近一条的 commit 把默认的 diff 格式从 aider 默认的 searh-replace 格式改成了 udiff 格式。我很感兴趣将默认的 diff 格式换成 udiff 格式的原因。
aider 官网有介绍什么模型适配什么样的 diff 格式 Edit formats | aider ，从他们的介绍来看， 只有 gpt-4 系列模型默认使用 udiff。
search-replace格式是不是，不方便直接生成emacs可以合并的格式？
我们改过来的目的是，减少格式之间转化。
比起合并格式。是不是在 python 端生成一个 ai 修改完后的完整的 buffer，直接发给 emacs，让 emacs 对比当前它缓存的 buffer 生成 diff preview，这样做会不会更简单？
我的想法在于，udiff 是 aider 已经实现过的 diff 格式，但是他的默认 diff 格式仍然是 search-replace，应该是有做过对比尝试的结果的吧？
aider有那么多diff格式我觉得很大程度是历史原因，以前的llm对格式的遵守程度有问题，现在的主流llm都好很多了，udiff只要没问题的话是可以直接apply的
Emigo还在非常早期的阶段，还没做到正经apply diff的部分，等真正实现的时候可能会遇到一些问题，就不一定会留udiff了
这不就是whole格式嘛，太耗tokens了，而且得等ai全部生成结束才有feedback，和aidermacs就没区别了，太慢
我仔细研究过aider代码，像udiff是一年前早期的实现，后面paul一直在专心优化search/replace，udiff就坑掉了，效果不好不一定是udiff的问题，而是udiff 的prompt太久没更新了。
毕竟aider基本算是paul的一人项目，他的精力也有限
我表达可能不够清楚。我的意思是，不管 diff 模式是什么，可以是 udiff 也可以是 search-replace。在 python 端处理 diff 完得到一个改好的 buffer，把改好的 buffer 发给 emacs，让 emacs 做对比。了，而不是把 diff patch 发给 emacs。
这么做其实和现在 aidermacs 的做法可能差不多。不过区别就是 aidermacs 目前是要解析 stdout 猜测什么文件可能会被更改，但是 emigo 可以不直接改文件，只发送改好的 buffer。
确实，我搜到了一个很早期 cursor 介绍他们的 diff 格式的文章，这个文章被删掉找不到了。他们的 diff 格式大概长这样：
确实 cursor 用的格式和 udiff 更像一些。
不过 cursor 有在 prompt 中强调，udiff 尽量是大块的偏完整的代码段，尽可能不要生成细小的代码段。
对，这样就是得等整个LLM的输出结束emacs才有变化，太慢了，ai没生成完之前只能干等，这就是aidermacs很大的问题
prompt细节之后还得持续优化，目前先把大功能做好，大佬欢迎一起来开发呀
大佬不敢当。有机会能做微小的改进优化，会 PR 的！
diff这部分的处理我们会更偏向 Cursor 的设计， 让AI尽量只发送diff（这样更快）， emigo来实现类似 magit git status 的体验。
因为有些代码太长， 如果让AI输出， 第一会非常慢， 第二超过AI上下文， AI还会会强制忽略一些输出， 这样很难生成 diff
