非常非常多的人对于笔记软件就是跟风，对于"内容管理"具体要怎么做才符合自己需求完全没有认真考虑过，导致"主流的笔记软件"江山代有才人出，各领风骚几年，后浪不断拍死前浪。
一旦开始思考，然后知道emacs有个现成的org系统可供使用，并且emacs本身提供了无限可能性，让你有可能实现自己的需求，那么喜欢折腾的人很难不转到emacs上。
windows操作系统下有个神器autohotkey，这个软件的运行完全基于你写的脚本，所以跟emacs一样，它也提供了无限可能性，这点是最吸引人的。
1 个赞
用copilot做过elisp性能优化和代码清理,还不错.高级的任务不是很成功,因为AI出现了幻觉用不存在的API.
1 个赞
感谢提供案例！ 假期我复刻一下 
elisp我也想学学，一直没开始
我幻想的是ai能不能自助的复刻出一个(rust版本的)emacs出来，解决当前emacs的所有痛点并集成所有有点 哈哈
幻觉是不是就是一本正经的瞎说？
2 个赞
你指的是 Emacs 煮咖啡？这是一个圈内梗……而且视频里面也只是打开了电源而已。要想实现复杂一些的功能，需要做的工作还有很多很多
1 个赞
对我个人来说，最有用的是日常工作需要的 Emacs 小函数，即便实现得不完善也无所谓，用一阵子也就扔了。AI 大大降低了写小函数的门槛。以前如果要实现一个功能，如果对内置函数不熟悉要花很久，算总时长其实并没有多少效率。但现在 AI 一下就写出来了。
所以我觉得 Emacs 的可定制性在 AI 时代能发挥出最大的优势，没有任何其它编辑器能比肩。即便不会写 elisp 也能快速糊一个出来，有种彻底松绑的感觉。 
至于是否主流其实无所谓，至少 AI 能让更多少人享受到定制 Emacs 提升效率的快乐了，是件大好事。
10 个赞
说的太对了。有啥需要先糊个能用的，多个能用的糊一起就可以搞个包。
AI 有个毛的能力重构.
用户体验上, AI 它看得见 TUI/GUI 吗? AI 有手指可以按快捷键吗? 它知道人类使用 emacs 时的痛点是什么吗? 它首先得能获得现实世界的反馈. 这又不是纯算法的东西, 用 AI 实现只能说是异想天开, 等哪天有人形 (或者说它自己有手指, 能和人类感同身受) 的 AI 出来再说吧
如果是用 AI 重写局部代码, 那早就已经实现了
看见tui/gui和按快捷键这个，AI真有这个能力，甚至在chatGPT还没有流行以前就有了，这方面最成功的应用应该是游戏外挂，可以实时截取电脑画面判断怎么操作键盘鼠标，对于这些工具来说，实现用手指按快捷键是低效的办法。
为了像真人按的，可以把脚本写成快捷键随机按错，鼠标点错，随机延迟几百毫秒按，产生的数据几乎与真人没有区别，技术上可以做到普通用户发现不了。
当然专业用户和游戏公司是一定可以发现的。但是有个词叫“同流合污”
哈哈 分享一下我最近的玩法 我以为emacs的书签功能和快捷键执行.sh脚本在服务器里面进行sdk目录切换、命令编译、git管理已经够高效的了 没想到写成内置命令是真的舒服，我发掘了一个新的玩法：使用windows下的cmd，一个开wsl 登命令行emacs 、一个开wsl通过ssh登服务器的命令行emacs、一个通过ssh登录嵌入式主板、一个在windows通过adb 拷贝文件，而且wsl里面支持一些windows平台的命令，可以直接用M-x 打开微信、特定网页(比如工作网页、ai问答网页)、特定目录(本地目录、RaiDrive)、跳转到特定路径的dirvish（尤其是服务器端需要频繁的目录跳转）、lsp查看内核函数、cmd窗口下可以Ctrl-Tab切换窗口、还能全屏
Emacs的org也是纯文本文件，对于AI来说同样也很适合输出呀。我觉得可能微调AI让其输出org文本反而是更现实的路径。
我已经快3个月没有打开Emacs了，我现在基本上就是Codex，花了4500费用写了7款商业软件
而且这7款商业软件全部都是AI 100%编写的，我只是设计，调整UI，约束边界
即使现在发表博客内容，都是语音输入法告诉AI，让AI代为发表博客的
PS： 以上是我的真实经历，实话实说，如果对AI有误解的同学建议深入用一下 claude code 和 codex，不引战
最近白嫖codex，是很厉害，写新功能，理解代码解决bug也还行，但是在嵌入式这方面对我调试与硬件相关的问题还是没有什么帮助。
3617 95% - redisplay_internal (C function)
1830 48% - redisplay--pre-redisplay-functions
1830 48% - run-hook-with-args
1830 48% treesit--pre-redisplay
1722 45% - jit-lock-function
1722 45% - jit-lock-fontify-now
1722 45% - jit-lock--run-functions
1722 45% - #<byte-code-function 3B3>
1722 45% - font-lock-fontify-region
1722 45% - font-lock-default-fontify-region
1722 45% - font-lock-fontify-syntactically-region
1722 45% - treesit-font-lock-fontify-region
1719 45% treesit-parser-root-node
3 0% - treesit--font-lock-fontify-region-1
1 0% - facep
1 0% internal-lisp-face-p
大佬，上面是我写一个大文件的测试情况，高cpu。能否试着用AI探索下emacs的treesitter下对大文件写操作的优化？其实滚动页面也有性能问题。
我倒是很愿意相信AI的能力，不过现在的 neomacs 实际也处于极早期的开发阶段，我很想知道大佬和AI联手能在优化这件事上做到什么地步。
PS: 请原谅我有点冒昧 
。。。，我确实很想知道AI对这个“毛线团”般的emacs有啥高见。
就你发的这些信息，并不能排除你是否装了什么低质量的插件，甚至连文件样本，用的什么 parser 都不解释
喂给大模型也是浪费算力
就拿这个测试吧，c-ts-mode打开，写文件。
(setq jit-lock-mode nil) 就能明显解决卡顿
需要我给你进一步的优化指引吗？
效果不明显。我当然不介意进一步继续优化，我很想知道AI能做到哪一步，是否能优化出不卡的状态。
- 你是否用干净的配置文件测试过
- 你的 CPU 型号
(setq jit-lock-mode nil)是否用 M-:执行的