有一些使用场景 markdown 不能满足要求呢？比如包含python代码块，要求动态生成结果。
插个题外话，用 emacs 写 latex 体验怎么样？听同学说以后有些作业必须要用 latex。
Jupyter, 请……用浏览器作为显示后端效果不要太好。
写了一下，感觉没有什么特别的优势。
Org 能根据数据处理画出 线性统计图吗？像excel 一样 画出 CPU load 图
Emacs 容易获得、各个平台下都能工作，作为构建的一环我看没什么问题。
你的场景中，比较难协调的应该是编辑 org-mode。如果仅仅是编辑（生成报告／文档放在 build 阶段），需要克服的困难又少了许多，我相信用其它编辑器也是可以的，只是体验可能稍有不同。
我遇到过最奇葩的场景是，把 Excel 作为构建的依赖（某个国产山寨机项目）。用一个 Excel 文件存放多语言资源，然后每次打开／保存这个超级大的 xls 文件至少等半个小时才能动弹。
因为是从上游厂商 fork 来的项目，需要经常 merge，不能全盘改。后来我想了一个「以奇葩攻奇葩」的方案：把 build 过程拆解了，我们自己修改的内容放在 xml，编译的时候跟 xls 合并。虽然 build 过程更奇葩了，但至少我们同事可以不必再编辑那个 xls，然后对于自己添加的资源也能 diff / 跟踪了（这点也很重要，我想象不到上游厂商是怎么对那个 xls 进行版本追踪的，下载到本地打开目视检查？）。
5 个赞
有些场景 jupyter 也不能满足需求，jupyter 的可定制性不如 orgmode。我的使用场景包括 html 自定义主题，html, js, python各种代码块之间的交叉调用。
被大佬说中了，确实和同事之间沟通最难的一环是 orgmode 的编辑。同事对 emacs 颇有微词。。。但是相比 pandoc 和 latex，orgmode 是最容易产出的方案。
现在程序员只知道 markdown，写项目文档时，我叫用 texinfo，结果还和别人起了争执。
1 个赞
听你这么一说，我就知道我现在觉得好玩（也实用）的 Common Lisp 是很少人用的了。。。
Hunchentoot 崛起~~~
（不过官方文档[我修改了自己的风格样式=> http://doc.celwk.com/hunchentoot.htm]有点点生涩，花了好几天重复阅读才慢慢理解得更深，还有现在要实践：Hunchentoot VS nodejs.Koa）
TeXinfo 本质上就是 LaTeX 啊。
GNU 当年是沒得 roff 用，只有 TeX 是 GPL 而且跨平台的才搞得 texinfo。
我还真沒见过有多少 GNU 以外的用 texinfo，人家要么都是用 DocBook, AsciiDoc。要么就是编程语言相关的 markup，乃至Qt 这样自已搞 markup。
如果不是什么大项目，讲真谁去花时间去学这个啊
我们用mediawiki，但是感觉不好用
不可能的，最多你自己用org-mode然后pandoc导出到docx/odt什么的。没有人会鸟你用什么破emacs 的
讲真，听说以前我们这有些人一起用过org来写文档，但是某个emacs用户不习惯org，所以 大家又去markdown->mediawiki了
上手挺快的。
要论上手快那还真不如 Asciidoc
什么是项目的依赖？没有被依赖的，就不能 (编译代码|写报告|…（感觉又陷入类似为什么用 Emacs）)?
我和我的 Boss 之间：我用 Emacs 写文档，TA 打印出来读，然后纸上写建议。我感觉超级合拍。
裸 Emacs 不好，但是配合 swiper, ivy, helm, pdf-tool, org-mode, company, org-noter, 超级棒的！(我大部分工作时间都是在 emacs 按 latex 的规则来处理文档的
太好了，这样我们就可以发展 emacs 啦。
我觉得 Emacs 把信息间的整合做到了极致，这是因为 Emacs 尊重我的选择，而不是软件开发者。只有我，才最接近知道“我”到底想干什么。
这个好厉害啊，愿闻其详。
写文档 org 最顺手，但是看文档， 真的是 info 最舒服。 magit 的手册，就是 org 写的，然后脚本生成 info，这真是一个好注意。
我用 texinfo 作为我自己 pdf 库文档的入口，主要是看重 info 浏览上的方便。
去年我开始认真学习 emacs 的时候， Emacs Intro 里有讲 texinfo 的，那个时候也不知道，info 浏览手册的便捷性，也是后来自己用 emacs 多了之后才觉得 texinfo 的优点。
org-brain 是个不错的想法，据说符合大脑的思维方式，我也正在尝试中。
诡异的 Emacs 用户。
没什么好详的，就是自己写了一个 xml <-> xls 工具，然后在 build 过程中增加合并的步骤。
我前面回复主要是想说，楼主所谓的依赖对非 Emacs 用户来说其实可以做到无感。主流的编辑器应该足以应付 org 文档的编辑，build 过程中的 Emacs 存在感就更低了。
我去年用过挺久org-brain, 这几天捡起来继续用了。 绝大部分emacs用户是用的默认配置，并且不写org的。
emacs三驾马车：org，magit，dird 然而我用得最多的只有magit，org仅限于写笔记而已…