目前这个包就是这么设计的，因为要考虑到在 edit buffer 中再打开 edit buffer 再打开 edit buffer…，所以【进入】和【退出】分别采用不同的按键。
如果你不需要嵌套进入，你可以试着改一下。
现在这个模式跟 magit 的操作方式是一样的，我觉得挺好的。
都是 C-c C-c 提交， C-c C-k 取消
没办法，个人使用时的心理模型跟 org-mode 的 source code 编辑一样，平时操作起来按 快捷键是靠肌肉记忆，hack 了一下基本上跟 org-mode 一样了：
(defun my/ad-comment-edit (orig-fun &optional block)
(if (string-prefix-p "*edit-indirect " (buffer-name))
(progn
(if (buffer-modified-p)
(edit-indirect-commit)
(edit-indirect-abort)))
(funcall orig-fun block)))
(advice-add 'comment-edit :around 'my/ad-comment-edit)
另外，我感觉如果出现嵌套编译注释的情况，就该反思是不是注释写得太复杂了，快捷键一 般来讲应该是为常用直观的场景进行设置，如果不常用估计也记不住。
1 个赞
已更名为 separedit.el
注释／文档中嵌代码块很常见，所以必须保证功能上可以应对这种情况，具体用什么键在其次。
另外，进入／提交／中断这几个键都是可定制的，不需要 advice：
1 个赞
似乎在 indirect buffer 里 markdown-mode-map 是不生效的？
这个带来的一个问题是，在 markdown-mode-map 里熟悉的按键绑定没有了……
通过手工开启 markdown-mode 似乎可以解决，不知道这是有意为之还是其他原因呢？
的确存在这个问题。因为此时的 keymap 都被覆盖了。但是如果直接 M-x markdown-mode 又会破坏编辑环境的设定。
我改了按键绑定，你获取新代码试试看。
试用了一下，可以了。
markdown-mode 的绑定可以使用了
改了之后出现新问题了，不该这么仓储推上去。
已修复，并写了测试，以后再怎么改都不会跑偏了。
其实我更好奇，什么代码的注释还有那么多代码
有的项目的文档直接写在注释里，码／档分离比较容易脱节。
文档里除了叙述性的文字，示范代码也是很重要的。有了示范代码，还可以在转成 html 之后，给读者提供一个可修改／运行的沙盒。
这种 documentation comment 在 rust 项目里大量的使用。 如这个例子
这样子，这些代码可以算在 doc test 。又在生成文档时，这些 test 也可以作为示例来显示
2 个赞
如果不要求ascii的话，或许可以试试org mode导出纯文本里标记代码块的符号。
;; ┌────
;; │ (use-package ghelp
;; │ :config (ghelp-global-minor-mode))
;; └────
另外screencast图加载不了。
没看懂:thinking:
或许可以考虑用
┌────
│ (use-package ghelp
│ :config (ghelp-global-minor-mode))
└────
代替
,--- elisp
| (foo \"bar\")
`---
？ 虽然第一个没法手打。但是好看不少。
README最下面的screencast加载不了。
代码块的外框不限定，可以自行添加定义。
如果这种外框使用普遍的话，可以考虑内置。
unicode 字符的确好看很多，打字其实不是问题，只要用其他工具，比如 snippet (定义一个 [s 表示方角代码框) 生成一个空白框：
┌────
│ $0
└────
然后由 separedit 打开编辑，就不需要手打 unicode 了。
我还以为是网络问题😅，应该是项目改名然后跟 gif 文件没对应上。干脆删掉得了，这两个 gif 很早录制的，过时了。
1 个赞
btw这个变量是干啥的
(defcustom separedit-continue-fill-column nil
"Use the remaining fill with of the source buffer in edit buffer."
:group 'separedit
:type 'boolean)
哦哦，那应该是“fill width”？
命名的确不太合适。
另，现在已经加了对上边提到的 unicode 代码框的支持：
不过刚发现一个问题，就是代码框 <language> 的名字不支持连词和特殊符号，下次统一再改了。
1 个赞