mac: open
linux: xdg-open
感谢分享。这个用在Windows 上配合 Typora 预览 Markdown，配合SumatraPDF 看PDF文件，真的太舒服了。最好再配合一个全局的Emacs 按键 ，赞 
可惜Typora 正式版后要开始收费了
1 个赞
现成的elpa包：open-with，你值得拥有
尝试了一下你说的这个openwith, 这个包只是绑定指定的后缀通过外部程序打开，对于只是希望打开pdf，音乐，视频 等格式的需求是很合适的，和Emacs 集成的很好。但是好像没法同时通过emacs 和 opera 打开 markdown 文件，还是需要什么设置？。
如果只是markdown，很简单啊，markdown-mode专门有个函数，是让你设置外部程序预览的，比如，我用的是marked2.app （你想用typora就设typora打开，可以建个小script借助Windows下类似于linux xdg-open或mac open的命令转下，如果没提供直接的终端接口）
(setq markdown-open-command "/Users/XXX/bin/Marked2")
如果你想在浏览器中打开，你开个浏览器，用那些实时预览mode就好了啊（markdown-mode自带的不能实时，但用预览命令就是打开到你的浏览器啊；当然它还提供了个emacs内部预览的方式）。
多谢，还不知道有这个命令，好用。不过通过 markdown-open 在typera 打开当前的markdown文件后，emacs的buffer就冻结了，需要多次 C-g 才能恢复。有选项关闭这个行为吗？
现在用 Emark，对于需要在 Emacs 中使用外部程序打开文件，有了更方便的方案。
比如 在 Dired 界面下，在需要用外部程序打开的文件上执行 embark-act， 我绑定了 C-.，然后按 x 就会用系统设定的默认程序打开相应的文件，非常方便，不需要特别的设置了。
Embark 确实是 Emacs 一大神器之一 
。
2 个赞
用法上写点介绍呗，看着像不同对象有不同执行命令快速选择？
我也是刚开始用 Emark，主要用的是两个命令： embark-act 和 embark-dwim ，其他还在慢慢探索中。
-
embark-act就是跟你想的一样，在不同对象上用，会弹出不同的命令菜单，类似于图形软件的右键弹出上下文菜单。这个主要用来解决知道了要执行的对象，但还不确定要执行什么命令的情况。命令是自动识别 Emacs 自带的命令，也可以自己定义。 -
embark-dwim我用的还不多，主要是替代xref-find-definitions'，这个命令相当于图形软件的左键点击命令，点了自动会执行相应的动作。比如如果可以执行 `xref-find-definitions’，它就直接进行跳转了，不会有提示命令的。
这位大佬在视频的最后部分有介绍 https://www.youtube.com/watch?v=5ffb2at2d7w
1 个赞
看着扩展性很强大，但是最后用的功能就那几个，天天弹选择菜单反而效率低？
我现在确定的功能都是肌肉记忆，补全主要靠snails，记不住菜单靠one-key.el
请教下，不知道embark相对于我的使用习惯有额外的优势？
我也不大喜欢弹窗 
，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 做好，如果这个方向不对，最多只能帮助用户减少一些全局按键绑定。