我也不大喜欢弹窗 
，embark 默认是 弹出一个buffer 列出命令以及详细解释，我是定义为 which-key 来展示，不知道是否可以集成到 one-key。emark 我也是需要的时候用一下，比如本贴提到这个就很合适用，还有就是在切换buffer 时，在 miniffer 中就想 kill 掉一些 buffer 时用。
感觉对你的流程，embark 可以做为一个补充的，需要的时候用一下 embark-act，它还可以应用于选择的区域。
which-key 的源代码我看过，主要是它要用户手动去写弹出菜单的布局，维护代价太大了， one-key.el 可以自动根据列表内容生成适合Emacs窗口的菜单，除了古老以外，我觉得 which-key 的方便性不如 one-key.el
我看完了这个帖子和视频，说一下我的个人想法（每个人习惯不一样哈）：
Embark 现在的交互有点类似 ivy 和 which-key 的集合，当然也可以换成 helm 那种风格，本质上是 “从光标处提取初始化的字符串 → 用户输入点内容过滤列表 → 切换命令菜单来执行匹配的内容
作为Anything的开发者之一（Helm的前身），我不看好embark, 理由如下：
- Anything和Helm这种项目之所以难以维护的原因就是80%的代码量都在 action list 这一端，比如找到文件，最常用的是打开文件，但是社区会增加很多额外的命令（比如用sudo打开、在另外窗口打开、比较多个标记的文件等），这种以 “逻辑对象” 为中心的设计，会导致任何人提的 action 都往 action list 里面塞，即使 90% 的 action 都不常用，为了强大的功能也要加上，长此以往没人有足够多的精力维护这么多不同方向的功能，这也是我为什么写 snails 的原因，补全框架做好搜索和过滤就行了，每个后端只做一个主要的功能，宁愿加一个新的后端，也不要往 action list 里面塞，代码量少方便维护，长期代码不变就稳定，不会发生原来一升级 Anything 就各种挂的问题，节省用户时间;
- 用的久会变成强迫症， Anything最开始是解决 ido 无法模糊搜索的痛点，最开始挺好用的，后面用的多了，社区觉得啥东西都要用 Anything 的风格才是正确的，比如代码补全要用 Anything、多个文件比对要用 Anything 、包管理要用 Anything、执行命令要用Anything、 grep也要用Anything, 甚至拷贝啥光标处的对象也要用Anything。我这么多年的用下来，从我的总结来说，只有搜索任务会用到，非搜索的任务要交给其他插件去解决，比如代码补全 company/autocomplete 就挺好，文件对比 ediff 很好，包管理就用专门的列表插件，执行命令smex已经非常直接， grep任务 color-moccur.el 和 我写的 color-rg.el 都很好用（固化窗口选择搜索文件比实时匹配更让人安全，因为不用担心插件退出状态的问题），拷贝光标处对象应该没有啥插件比 thing-edit.el 更直接高效的;
- Emacser的使用比重是场景化的，而不是以搜索为中心的，比如编辑文件的时候，company/yas/dabbrev/ace-jump/thing-edit的作用更大，重构文件时 grep 类插件作用更大，浏览文件 dired/projectile 作用更大，只有切换 buffer/opened file/bookmark 的时候搜索类插件才是最合适的，从效率讲，如果不要弹出搜索菜单、命令菜单和补全菜单就可以把事情最快的做完，才是最舒服的环境。
如果按照Anything/Helm那样的集大成发展，我觉得 embark 非常有可能发展成 Anything/Helm 那样的巨无霸插件的效果 看着琳琅满目的功能，给人感觉很强大，用户只是想拥有自己平常也很少用的功能，开发者也疲于奔命，代码越来越复杂，维护吃力，经常更新后还不稳定
1 个赞
我入门 Emacs 比较晚，没用过 Anything / Helm 。看你这么说， Embark 的行为是和 Helm 比较像吗？
我也不赞同这种集大成的发展。 经过了 helm ivy 等教训以后，现在 Emacs 社区看起来是有这方面的意识了，尽量保证包的轻量化，方便用户自由集成。比如最近比较流行的 consult ，发展的比较成熟了，用户也想加入很多类似 helm 的功能，但作者都是把他们放在单独的包（ 如 consult-dir)。
目前我觉得能用 Embark 解决一些小问题就好，不求什么都用它 。
Embark从视频看，一个窗口负责搜索过滤，类似 Helm 的多后端同时过滤，当需要 Action List提示的时候，用另外一个窗口显示 Action List。
从交互易用性看，还不如 Helm 的 Tab 切换 Candiate Buffer/Action Buffer 的设计。
但是从博客和视频看，Action List有太多额外的功能，非常像 Helm 的发展路径，作者使劲往搜索框架里面开发各种非搜索Action功能，其实大多数Action都不如在实际场景下用别的插件方便。
1 个赞
vertico的卖点就是一个插件专注一件事。使用embark感觉就是把之前丢的都捡回来了，可能还没以前的体验好。个中得失还是挺微妙的。
确实，embark除了export这个偶尔代替ivy的occur还比较实用，其他的比如类dwim功能感觉用的真不多。。。
vertico的生态发展起来估计不亚于ivy/helm这种重量级的，优点可能在于核心做的比较精简，模块化程度更高吧。
embark 比起 helm ivy 这些我看到的区别一是不光作用在 minibuffer 中，比如说在 variable 上 embark-dwim 的默认操作就是 find-definition。二是操作的对象是 object，不需要像 ivy 每个函数都定义 action，而是可以调用已有函数，一定程度上减轻维护代价。
上面那个博客是第三方作者介绍自己咋用 embark 的，函数都是自己添加的，事实上我觉得 embark 默认能支持好 Emacs 内置的 object 就好（buffer，file），目前貌似已经是这样做的，然后函数基本都是已有的。添加功能或者与别的插件交互应该通过第三方插件，比如说想在 org-cite 上面打开 bibtex entry， note, file 就可以用 citar
如果是从这种角度看，应该着重放在环境对象感知和自定义触发函数的设计上，不要以补全为中心。
从我个人使用习惯看，我比较怀疑同一个对象是否都是 dwim 第一个动作？比如光标在一个符号上，有可能的动作是复制、删除、找定义、找引用甚至是记录当前位置等等，环境的不同动作不同会回到弹出菜单选择上。
embark 是否长期有价值，还是要看能否把 dwim 做好，如果这个方向不对，最多只能帮助用户减少一些全局按键绑定。
我感觉 dwim 够呛，然后只能回到菜单选择，靠用户肌肉记忆。你说的对，那样确实只是帮用户绑定了一些按键
只能说在补全方面较 helm ivy 的方式一个个绑定的方式稍微有些进步
可以用函数 browse-url 在 dired 中快捷键是 W
外部命令打开当前文件
(browse-url buffer-file-name)
外部命令打开当前文件夹
(browse-url default-directory)