我的建议是，如果你自己不用，就删除，因为维护不好，出了问题也不能及时发现，如果你的包足够好用，doom会包含你的包配置
1 个赞
专注于核心功能的稳定可靠我觉得更重要
1 个赞
ok
我在思考怎么解决这个问题
只要不push，然后勤于清理，用magit rebase squash一下，commit本身的问题应该不会很大吧？
1 个赞
@chunhui_true 这个功能实现了，在这个PR里面，稳定后merge：BREAKING CHANGE: Revamp Transient Menus for Enhanced Usability by MatthewZMD · Pull Request #42 · MatthewZMD/aidermacs · GitHub
-
临时文件的方式：你可以使用
aidermacs-create-session-scratchpad创建一个临时的空白文件，然后把函数或者代码片段复制到这个文件里，保存后，Aider 就可以读取并使用了。 -
从其他文件添加：你也可以在别的文件里通过
aidermacs-add-file-to-session命令，选择要添加的文件，这样 Aider 也能读取该文件的内容。这个命令可以让你把任何文件添加到 Aider 的会话中。
欢迎试用，看看有没有满足你的需求~
1 个赞
新版Aidermacs已正式上线。
1 个赞
目前 agent 程度越来越高的 AI 写代码工具都抛弃了 diff preview 让用户选择是否接受的形式，而是选择了直接改代码，改完代码以后再展示给用户修改过后的代码，然后让用户自己选择是否要 undo。
比如 cursor composer 就是这么做的。
个人认为 AI 直接改代码主要应该是写 agenetic 的 workflow 的逻辑更好写。试想一下，如果 AI 改了一段代码被用户拒绝了，那么后续的 agentic 的 workflow 还怎么走，是不是感觉走不下去了？所以不如干脆一次性让 AI 直接把代码全部都改好了，然后再让用户自己决定是否 undo。
cursor 等工具是逐渐从 chat + apply (chat + apply 过程中 cursor 会提供 diff preview 让用户决定是否接受代码）过渡到现在的 agentic workflow 的。 而 aider 从一开始就是一个高度 agentic 的工具，从一开始就没有做 cursor chat 那样的交互形式。
因此随着 AI 的智能程度越来越高，抛弃 diff-preview 应该是大势所趋。就像你招了一个大头兵，那你肯定不会让大头兵每写一段代码就来给你看看问你要不要接受，肯定是大头兵把所有的代码都写好了，你再一整个整体看哪里有问题哪里没问题。
2 个赞
diff 的目的是看AI写的对不对，要不要调方向，要不是闷头改他们会一堆不必要的代码
aider的/ask和/code分开的设计，以及/architect先给diff再问用户要不要改动的设计，这套流程加上Aidermacs的语法高亮，都还算ok的解决提前判断AI写的对不对要不要改方向的需求。
目前这流程有两个问题：
- diff只显示在aider进程里面，尽管有语法高亮，缺少文件具体的前后文context，有时候还是不足以让人判断AI写的是否正确
- 有时候真正上手修改代码的AI并没把前面用
/ask或者/architect设计的方案完全执行，真正上手改动的diff和前面设计的diff有些不一样，甚至改动的AI把代码完全改崩，然后弹出一堆linting错误也是出现过
第二个问题从Aidermacs有点不好解决，是目前使用不同AI分别设计和修改代码的一个弊端，可能需要Aider上游想想办法。
但第一个问题是从Emacs端可以解决的：
保持Agentic workflow，随便那些Agent改来改去，最后让Emacs来兜底，以更直观的方式来判断要不要undo
有用户提出希望有类似cursor的code review / accept功能, 我通过ediff初步实现了，目前还不稳定，接下来几天得继续完善一下，先放到ediff的branch里面啦：
2 个赞
Ediff单文件功能基本稳定了，多文件还有点小bug，不影响使用。
现在aidermacs修改完，会自动弹出一个ediff窗口前后比较，可以通过a/b等ediff快捷键恢复aider修改前的状态，也可以自己进入buffer修改具体内容，比单纯什么accept / reject强大太多了，还得是Emacs生态。
最新版master可以试用了！
1 个赞
我的解决方法是实现了不依赖aider的包eureka，不过最近没怎么用也就没怎么完善。
我目前其实没有commit不被允许的问题，只是提出来aider这个方式可能会在某些公司不合适。
我在eureka中也实现了通过ediff来review修改的功能。 多文件ediff我是这么实现的：在临时目录创建跟项目相同的目录结构，把大模型修改后的文件放到临时目录中，然后ediff项目目录和临时目录。
不过有些遗留问题，例如怎么在合并完之后删除临时目录；目录比较深的时候，ediff session窗口需要一层层进到深处的文件目录中，比较繁琐。
这个只能控制会不会执行git commit，没法控制是否直接修改文件内容。
没错，我也是这样做的！（只是反过来了，把LLM修改前的文件放到临时目录了，主要还是Aider直接更改文件了）功能已经完成了，只是有点QOL的问题和一些edge case没打磨好，所以push到master，大家一起试用起来吧
我之前没看到你的eureka，有空来取取经
我写eureka最主要就是因为aider会直接修改文件，我实在是不喜欢。
eureka额外的我觉得还算可取之处的是结合lsp客户端，根据incoming calls和outgoing calls自动计算当前文件的依赖来生成（一部分）context。 Emacs其它llm工具都没有类似功能。但是这个功能实际效果有待评估，毕竟我也没太怎么用eureka。
其它的还有使用treesitter生成文件的outline，也是模仿aider。别的就没了。
Aidermacs打磨好了我完全不介意抛弃eureka切换过来，哈哈。毕竟有aider这个很好的基础。
1 个赞
今天刚修了vterm的bug，ediff可以在vterm用了。
大佬欢迎一起来玩Aidermacs呀！
不知道能不能利用 git worktree 的机制，让 aider 工作在独立的 worktree，这样就不用担心它搞乱代码了，然后 diff 的时候也（应该）会比较方便？