直接贴大段大段的生成式ai的spam确实很无趣,非常无趣. 你自己的表达非常完整,中间那段ai删掉没啥问题. 当然,你不乐意看见别人对你有意见的话,也可以删除我这个帖子.
你当我是权限狗啊 :doge: 如果可以,我想置顶你这句话
老哥,我真的没有批判你重复造轮子的行为,我认为你fork是合理的。
我其实想说的是多行输入有bracketed-paste,其实不需要很多复杂的实现。我只是在说这个多行输入上的造轮子的事情,而不是aidermacs fork这个行为不合理。
如果我的表达造成了误解,我再次向你道歉。
最后,我一开始批判你的时候,我确实自身也有自己的心情不好的原因,导致说了更重的话,我再次向你道歉,我也重新更新了我的“奴隶”那段话的一整段话,重新表达了我的观点。当然这仅仅是我个人的观点。
虽然一开始确实是我不对,我用了 proactive 的语气批判了你的行为。我现在已经将这句话的语气重写,仅表达我的个人观点,而不对你有任何的批判。我希望我们能够心平气和地讨论问题。
了解了,我收回前面对你的反驳,对不起,我向你道歉,我的反应也比较大了。
我完全理解你的想法,这或许正是我们潜意识中对AI目前展现出的能力产生抵触的一种外在体现。但如果细想一下,论坛本就是各种观点交锋的地方——你表达的是你的观点,我表达的是我的观点,而 AI 生成的内容同样也是一种观点。当它被发布在论坛的回复框中,本质上只是观点中的一部分,而并非某种客观标准。
可能因为粘贴的AI文本比较长,让他看起来有种权威性,这不是我的本意,而且这恰恰是当前LLM最危险的地方之一:AI输出的内容越多,我们往往越难以逐一核查细节,跟review几百行PR更容易点LGTM的道理一样哈哈哈。然而正是在这种情况下,AI hallucinate的风险也更高。作为日常高强度使用AI的人,AI的hallucination已经习以为常了,事实上我前面粘贴上来的内容,我已经删除了一条AI编的部分了,GPT4o真的不太行。
回到正题,我的立场前文写的非常清楚了,我认为Aider.el的作者并没有认真尝试理解我和CeleritasCelery的PR和评论,我和作者的沟通也经历了从3周前的友好沟通到今天完全放弃另开fork也是很长一段拉扯。因此,我前面用ChatGPT的目的就是用中文整理我们之前在Github沟通中已经address过的地方,只是写个Aider作者看的,不是写给吃瓜群众看的,希望大家能理解,而AI,作为一个高效的信息整理工具,也完成了我的要求。
好了,题外话就说到这,再继续下去我得警告我自己偏移话题了,如想继续讨论咱另开新帖。
这个方案是可行的 之前有位贡献者用doom 他就自己写了doom 的菜单 主文件aider.el 我希望尽量减少依赖 新的需要依赖的功能放在额外的文件里 比如aider-doom.el 这也是他的想法
所以这个功能也许叫做aider-vterm.el 问题是 谁来写 谁来维护呢?我个人并没有很强的意愿来做这件事 因为comint的功能虽然有限 但是足够满足我的需要 而且我也并不是vterm专家 不见得可以长期维护这个额外的功能 doom菜单我有时候去照顾一下 因为我自己不用doom
才下班 才有时间来回复帖子 可能不是很及时 见谅
另外 祝大家都有个好心情 参与做开源分享的事情 本来就是自利利他 开开心心很重要 项目有人喜欢 很高兴
操作里有不少添加文件的操作,但是没有罗列当前已添加文件,移除已添加文件的操作。
虽然可以在 session 里通过 aider 的命令罗列和删除,操作起来也不算麻烦,不过是不是也能提供一些方便的操作?
不过目前其实我比较少会删除文件,有时想精简一下当前 context 可能会有用吧。
确实没有加/drop 命令. 它好像可以带文件名, 或者不带文件名. 如果需要经常带文件名. 加个菜单项可以省去粘贴文件名的时间, 今晚我去改一改
我自己一般是完成一个task以后, reset以后加其他文件开始新的工作 reset会清除所有文件和聊天记录
平时没怎么用列出已经加的文件, 因为每次使用ask, code, architect之类, output的最后都已经会列出已经加的文件列表
现在的菜单项有些冗余, 关于add / drop文件, 以及reset / clear这方面, 我再想想如何精简
原来如此,reset 也可以,本身删除的需求确实没那么高。
菜单或许可以做成像 magit 一样的? 按照功能分组,有二级的菜单,不过可能降低了一些便捷性。
是的, 有道理. 最常用的功能比如add保留在顶层, 减少按键次数; 不常用的功能放到二级菜单或者类似的其他办法
顶层菜单太复杂对user experience也不好 我现在更喜欢做减法大于加法 aider提供的各种命令 启动参数已经非常多甚至有些复杂了
除add文件之外,能否有add一个函数,add一段代码这样的功能。 add 弹出类似magit一样的界面,选文件。或者函数 然后添加到会话中 然后ask。。。。
据我所知, aider CLI本身并不直接带有这样的考虑, 得自己拷贝粘贴过去, 像去问chatgpt问题一样.
aider.el的一个基本考虑是希望结合emacs lisp的编程能力把buffer里用户关心的context作为prompt的一部分发给aider, 减轻用户操作的负担. 有好几个命令都是考虑 当前函数, 或者选中代码的, 比如
-
询问问题: aider-ask-question: 在当前上下文中向Aider询问有关代码的问题。如果选择了一个区域,使用区域作为上下文。如果没有选定区域, 光标在某个函数里, 那么它会问关于那个函数的问题
-
修改代码 aider-function-or-region-refactor:如果选择了一个区域,辅助重构或者修改所选区域。否则,重构或者修改光标下所在函数
-
多行注释的in-place新代码生成 aider-implement-todo: 如果有多行注释的选择区域,要求在那个位置实现这些注释中描述需求的代码
-
单元测试相关功能
这些功能我自己都在用, 好使的. 它们也都在菜单里
这只是我有限的经验总结的想法 请大家多多提意见 谢谢
为了实现发送多行代码块到aider session的效果, 我的选择是在代码块前后加上{aider … aider} tag. 不然的话aider会把它们当成多行命令, 一行一行逐一执行. 这个实现比较安全, 目前还没翻车. 不过, 可能和有些同学交流的时候, 没太说清楚, 让他误会了.
你描述的很清楚,我没有误会。我理解你的想法,但不理解你的实现具体“安全”在哪里,更不理解我们之前的PR具体“不安全”在哪里。
但没关系,我们想法不同,你继续你的Aider.el,我继续我的Aidermacs。Aidermacs 在昨天和今天两天时间已经加入了非常多的新功能:
- vterm和comint双选择
aidermacs--current-output
彻底打通Emacs与aider输入输出通道M-x aidermacs-list-added-files
添加文件 和M-x aidermacs-drop-file
移除文件
- 重新整理 transient 菜单,引入了二级菜单,强烈提升用户体验
详情可以看:GitHub - MatthewZMD/aidermacs: AI Pair Programming in Emacs
同学, 我好心劝一句, 如果是上班拿工资的人, 白天该上班好好上班. 现在这个经济形势下, 大家好好把饭碗捧牢是正事. 当然这不是我该管的事情. 之前沟通上有些摩擦, 你现在也还生气, 我也有一定责任. 那个时候我这也该睡觉啦. 第二天还要上班呢.
感谢提醒,最近在休假,不用担心我的工作,况且这几个功能虽然花些时间,又没有什么难的,写写还挺有意思。
我就是不想直接拒绝而已 公开吵架 太难看 有些code我不想merge 同意了以后 不管我自己熟悉不熟悉 将来就要维护它 我只是量力而行
当然 只是我个人的判断 对于这样古老的编辑器 如果有 品行好 有才华的年轻人 愿意贡献自己的时间帮助做emacs 相关的事情 对于这个community 而言 也是好事情 因为之前很多人都担心现在年轻人不再使用emacs
这又回到这一整个月包括昨天和今天都重复不下几十遍的事了,你觉得不够stable却又拿不出合理理由,什么都是你觉得,都是你的判断……这当然可以,毕竟是你的项目。但开源软件的协作和你公司里的传统工作模式可能会有些区别,你可能不够了解社区模式,也不够了解elisp。
总之我们的分歧在我Fork之后就没有任何意义了,这个话题到此为止,之后我不会再回复关于之前PR/我们分歧方面的任何内容。一切交给用户自己去判断吧。
当然,关于Aider和Aider.el或Aidermacs的功能,欢迎一起聊,毕竟Emacs社区没几个人集成Aider了。
另外,如果你的Aider.el要是实现了什么新功能,欢迎来我的帖子宣传,好的功能大家一起用才是好事。
那基本就是我想的功能。
比如我针对一个函数问了一个问题或让aider重构修改。它会不会自己去找函数相关的函数?这个需要aider.el来告诉它,还是它自己作?
希望这些功能对你有用。就是因为有和你类似的需求,意外的发现aider可以识别代码文件里的语法单元比如函数,正好elisp可以识别光标下的语法单元,才这么做的。
如果是想解释代码,并且依赖的函数也在这个文件里,或者在已经加的其他文件里,我几个月前试过,可以用ask让它recursive的解释函数,比如,please recursively explain xx function。甚至还可以让它画dependency ascii chart. 具体效果好坏好像也看用哪个模型。现在想来模型已经更聪明了吧。
aider.el没有针对递归解释代码的要求做一个函数。虽然尝试这件事的时候很兴奋,实际上我并没有用很多次,因此也不值得占一个宝贵的菜单项。不过,如果你愿意用helm的话,可以尝试也加载aider-helm.el。它的作用是把以前用过的prompt存下来,按照使用频率排序。所以如果第一次你输入这样的要求prompt, 下次helm的模糊匹配就会起作用,敲很少的字就能找到以前用过的这个prompt。这也有点接近菜单项了
复杂的重构修改,我觉得要小心, 不要高估AI的智商。prompt越具体越好。尽量多提供有用的信息给aider,和非常具体要做什么事情的指示。即便如此,也要小心检查产生的结果,所以这个功能我用的/architect. 它会提供change供用户审核,同意了再make change,代价是多花一点token也就是钱。recursive修改的话,最好说清楚目的,和具体要改哪些函数,怎么改。当然,更安全一点的是,逐步让它做小的修改,并且经常运行单元测试。