论坛链接： https://org-roam.discourse.group/t/prototype-transclusion-block-reference-with-emacs-org-mode/830
GitHub链接:
用了一段时间roam-research做摘录.
作为 从底层支持双链接+小粒度块引用 的首款笔记产品,RR一系列细节打磨的真的很不错,也有着不错的扩展性,迁移性,和发展前景(据说最近拿到了big funding)
但是文字输入体验恐怕一辈子也追不上emacs这个主打编辑功能,而且扩展性几乎变态的软件
而且在大纲模式下,缺失类似shift-tab循环折叠的快捷键,实在是不利于输入长文本(卡片盒笔记法过于意识流,个人不喜)
现在这个消息放出,感觉在emacs中用上块引用不远了呢
这个是基于org-roam的吗？
是的，很有希望合并到org-roam上游。
我今天竟然考虑是否要转向 Obsidian……我觉得嵌套页面功能挺好的。这个恐怕 org-roam 实现不了
印象深刻，基于id链接感觉更通用。
但是目前没有想到合适的应用场景，似乎直接用id链接，点击跳转查看或编辑也可以？似乎是锦上添花，而非非他莫属。
希望大家能讨论一下块引用功能的实际应用场景。
roam-research 是全栈 clojure 项目，应该很快功能就会迭代上来。
org roam实际使用中还是觉得粒度太大，不敢开太多条目，但是这个又跟zettelkasten方法有点冲突。有块引用爽多了。
我理解的zettelkasten是小而多文件模式
实际用起来就是每个点都开个文件, 感觉有点压力.
我的笔记是记在一个org文件中的，挺期待这个功能的。
这个就讲究知识体系的内化,而非知识收藏(简单的复制粘贴下载),配合搜索功能
如果roam可以像org-brain一样，支持以heading而非file作为基本的笔记单位就好了，不过这个功能已经被推迟好几次了 Show back-link to current headline (not current file) · Issue #801 · org-roam/org-roam
个人同样也非常期待此功能，觉得org大纲+块引用才是笔记系统最优方案。 层次清晰，方便回顾，还省下了整理标签的功夫。
是的，卡片盒笔记法的实现方式大多是一个笔记一个文件，我觉得原因一说是沿袭自卢曼「一个笔记-一个卡片-一个文件」，但是卢曼用一个卡片主要是为了方便唯一编号，进而构建联系。然而如今，笔记载体在从物理实体的卡片升级到数字笔记的过程，我们有更多的方法唯一表示笔记，执着于文件已不再必要，甚至heading的ID是比文件名更为可靠的标识方法。
因此，现在大部分是基于文件实现还是从逻辑复杂度出发的吧。毕竟文件与笔记的逻辑对应关系很明确。而对于heading而言，可能是通常意义的笔记，也可能是笔记中的大纲标题，我没有仔细考虑过，如果等同对待是否会有问题。brain也是先支持的文件笔记，再支持的heading笔记。
采用文件组织的另一弊端是把知识管理和日程管理再次割裂。因为multiple small files对于agenda而言简直是灾难。而知识管理+项目管理的无缝结合本来是org-mode的优势。
我觉得卡片盒笔记不是说反对大纲层级，而是说除了大纲层级之外多考虑其他的联系方式：引用与被引用，笔记的周围视觉，关键词等。如果是像某些人说的，用卡片盒笔记法主要原因是不用考虑笔记放在哪里。那其实把所有笔记作为heading放在一个org文件也是一样的。
目前基于org-brain加了Backlink的展示，还很粗略，只是简单满足个人当前需求。
关于笔记实践方法的更多讨论参见 对比 org-roam 和 org-brain - #19，来自 yuchen-lea
我是赞同多而小文件形式,目前个人的理解是:
使用多文件的形式,是有利于记录无序的思维和单次有限的知识吸收,避免多次整理(相对于大纲的层次性).
至于相关主题的编写,利用backlink和tag进行联系和过滤.
能有块引用功能是更好的,有利于联系以前的文件.
为什么这么说呢？agenda的初衷不就是将分散在不同文件的日程收集起来统一展示嘛。
我个人也是比较倾向多文件形式，org-mode在处理多文件方面是有挺大优势的。而且多文件也能配合headline，再加上org-roam已经支持对headline的引用了，两者综合起来的效果挺不错的。
曾经在哪里看过，建议把roam的目录和agenda分开，Roam 的开发者说：
The reasons why Org-roam works better with small files is that exact opposite of why Org-agenda works better with big files.
出处：
不知你说的多文件的多是多少数量级呢？我也不是只用一个大文件，目前一共有近50个文件，最大的将近2M；但是有数万个headings。如果只考虑知识卡片的话，也得有几千个吧。按照roam的方法，每个笔记一个文件，要加数千个小文件到agenda list，我会很担心emacs performance。（不少人有类似的担忧：Combining normal org-files and org-roam : orgmode）
在我的理解中，agenda处理的基本单位是headline，比如说我有一个关于「org-roam」的大纲，标记了周期性计划以便跟进开发进度。如果现在这个大纲变成了一个文件，我不太清楚文件是否能展示在agenda中。或者我需要在这个文件中再新建一个名为「跟进org-roam开发进度」的headline？
严格来讲，不是多文件的形式，而是无层次的组织结构，有利于记录无序的思维和单次有限的知识吸收。在一个目录中的许多无层次的文件和在一个文件的许多无层次的大纲，本质都是无层次的组织结构。这就是为什么我说「把所有笔记作为heading放在一个org文件也是一样的」。
因此，个人之见，多而小文件和 少而大文件 在知识管理角度来看没有本质区别。关键是目前功能的实现是应用在什么对象。比如说，以我所知，列视图只能用于大纲，无法用于文件。roam的backlink是应用于文件（诚如 @VagrantJoker 所说，roam支持了标题的引用，但是它会在该文件的标题2的反向链接中，展示链接到该文件标题1的条目，因此很明显，基本单位是文件，具体实例）
我也很推荐在大纲之外，建立笔记之间更多的关联。毕竟联想是理解掌握、乃至迁移运用的关键。从无到有当然是进步，但是随着笔记数量的增长，新的问题会出现：
（来自我坛某友，欢迎告知来源）因为backlink只是反映了「引用」这一种关系，笔记之间的关系是很多的：影响、相反、相似等等（更多讨论参见此处），因此在backlink和tag的联系之上，我觉得还需要额外的结构，说明具体是怎样的关系（fine-grained labeled associations）。
目前这种实现方式基于ID，所以从粒度来讲，依然是大纲，没有变得更细。所以想知道与直接的ID链接到大纲相比，它扩展了哪些应用场景？
我目前的笔记数量只有近千个，和u/ftrx提到的一样，在我的机器上第一次打开agenda的时候有点慢，后续操作无明显卡顿，考虑到我重启emacs的频率不高，我认为这是可以接受的。
不需要，将org-roam-title-sources设置为'headline后与平常org操作相同。
关于性能,主要还是在于org的解析, 多而小文件和少而大文件在同样内容的情况下应该差距不大,推荐配置
(setq org-roam-db-gc-threhold most-positive-fixnum)
这个问题我觉得是无法避免的,目前可以通过Exclude和Buffer Network来过滤
就知识内容而言,没太多差别,但独立文件可以赋予更多独立的属性,如tag,至于应用场景,我目前主要用于过滤.