昵称又不能直接显示那设置昵称有什么用

不是先维护一个索引，如果预先维护一个结构，那就失去 daily notes 的意义了。

要预先维护的东西有两种，一是主题锚文本或子主题（roam research 或 logseq），思源如果要写成 [[主题]]：子主题 下级节点不会展开，这个信息可以写在子节点里；二是局部承接关系，conor 在下面的视频里做过一点演示，在他觉得某段话可能紧接在过去记录的某段话之后时，就会用块引用把两段话链接一下。

这个视频

我是这样做整理的 ↓

最重要的第一步：判断当前这个主题究竟需不需要做整理。用几个具体的切入角度来说：

1. 对当前这个主题，自己花费时间去整理，其效果是不是真的比插入个 SQL 块随机查看更好？
2. 如果自己整理的效果只比随机查看好一点点，有没有必要花这个时间？
3. 如果这是一些不对外公开、仅供自己个人查阅的笔记，有必要必要花这个时间？

只要认真对待这一步，就能节约大量的时间精力，毕竟「整理」也不是什么天经地义的事，比如像 code snippets 这种笔记哪怕在传统笔记工具上也没多大必要整理，有个全局搜索就行了。就我所见，以很多人对大主题长文本的驾驭能力，整理半天可能还真的不如直接用 SQL 块随机查看。所以我的感觉是，只有出于任务不得不做，或者对某个主题有了比较深度的思考，才有必要去整理。

第二步，如果真的要整理某个主题了，我就先阅览反链里的所有资料，这个过程中可能做一点修改或者添加；把所有反链资料看熟之后，这个主题的结构就已经开始在脑海里涌现了，然后我就先在正文区把它记录下来，比如我觉得这个话题得分三个主要部分来讲，就先在正文里写三个标题

# part 1
# part 2
# part 3

最关键的一点是，到这里为止都不需要把所有反链内容转移到正文 。等结构思考得差不多了，再把侧栏反链的内容直接拖向它应该在的地方。如果一开始就把所有反链拖进正文，整理起来肯定是超级麻烦的，反链在底部的大纲型双链笔记其实也有这个问题，它们不分屏的话得不断上下翻动。

只要结构梳理完了，后期整理是很轻松的。更复杂的结构我直接用 scapple 或 draw.io 整理，换句话说如果非要把内容整理到正文编辑器里，这种复杂结构多少会损失一些，还不如直接嵌入绘图，顶多再往图上插几个链接 ，这同样是一种整理。我写一万字以上的文章，背后一般都有包含近百个节点的 scapple 草稿，但最后真正能反映到正文里的大概不到一半，这是文章比起图形的局限性，所以「整理」这件事的内涵也不只是拖反链。

总结来说，那些不整理的东西之所以不整理是为了节约时间，这种理念救不了强迫症；而那些要整理的东西之所以要整理是因为每个人自己的思考是独一无二的，这种理念救不了抄书匠。整理 daily notes 还可以列出很多细节技巧，但更重要的还是对「整理」这件事本身的看法，后期的整理并不是在为前期的懒惰买单，而是在有了充足的素材之后进行更全面更深入的思考，传统记录方式其实包含了一个隐藏意图——想一开始就在舒适区内把逻辑结构安排好，那种做法才是真正的偷懒，而且这懒往往还偷不成。

The pattern of the thing precedes the thing. I fill in the gaps of the crossword at any spot I happen to choose. These bits I write on index cards until the novel is done.

＋1

另外，如果光标在列表里，连续按 ctrl a 不能选中整篇文档

这种功能最好还是由官方来加...... 用 css 实现标题块编号有三个问题，第一是长文档会动态加载，如果滚动到底部，css 只能对已加载的部分计数导致序号不准确，第二是 css 计数没法忽略 SQL 块中的标题块，第三就是侧栏 TOC 里没序号。

文档块转标题块跟合并其实是两种不同的功能

在电脑上不需要先切换思源笔记然后按 alt+5 打开日记，我是靠 url scheme 做个 quicker 动作，可以一键跳转到思源笔记并转到今日日记

[[复合嵌套[[语法]]]]不会在这里生效，在 roam research 里，把「唯物论」重命名为「唯物主义」来做一次合并，后续会发生这两件事：

1. 两个页面的正文会直接拼接起来；
2. 现在只剩下一个叫「唯物主义」的页面了，其它笔记里对「唯物论」的引用锚文本会全局更新，从 [[唯物论]] 变成 [[唯物主义]]，锚文本不会不断变长；

嵌套语法只会在使用者主动那样写的时候才会出现，其它功能都不会自动生成嵌套形式的锚文本，现在它最大的用途是在没有文档树的大纲双链笔记里达到一种子文档的效果，比如 [[[[父主题]]：子主题]]

是个问题

请教一个问题，可以根据某个块是否包含某个特定标签来修改这个块的文字颜色吗（用块属性没有直接写标签方便）

.protyle-background {
    display: none;
}

SQL 块 +1

这是个问题，光标不在编辑区的时候，不光 ctrl+f，ctrl+w 也用不了

设置界面也是这样

现在它直接出不来了 😳（重建索引也不行）

+1，这个合并导出的逻辑还是很直观的，子文档变成父文档里的一级标题，然后子文档里的一级标题变成二级标题，各标题依次降级就行了

要的就是这种效果 ，我一个人的背书效果是有限的，而且如果始终只有我一个人背书非常容易激起逆反心理。所以我前期只能先提供一个小模因，只有广泛讨论的风气被带起来了，大家才会觉得“这个东西是我看完多个帖子后，凭自己的思考能力总结出来的，而不是某个 KOL 灌输给我的”，达不到这种效果就终结不了思源社区的双链无用论，所以你们写比我写重要得多 🤣。

前排

之前我发的那个帖子里的内容太简陋了，这两天先发篇新文章补充一下

「conor 式的 daily notes 流程」当然没有出处，是我自己说的 ，拉上 conor 这个工具人只是为了起个背书作用，roam research 中的很多用法在其它软件上（哪怕是大纲双链笔记）都是失灵的，我只能说一些更加通用的用法和原则，以原则为主

先占楼再看

疑虑 1：

* foo
  * bar

如果第一层的 i 只包含 * foo 不包含 * bar 了，会影响对 * foo 及其子列表的拖动和查询吗？这个太重要了。如果不能根据父节点查出子节点了，问题很大。

疑虑 2：

我分析问题的习惯是这样，一件事要先评估做与不做，而不是一开始就一头扎进对具体做法的思考。

现在一炮三响对于熟练用户来说其实是很好解决的，就算要改进，我感觉主帖里写的这种改进方案带来的提升真的非常之小，还可能带来新的问题，而且也并没有提升对新手的友好程度（因为 l + i + p 的基本模型还是没变，如果一个新手从只会用 ctrl+p 进化到开始用 SQL 了，他在这轮改进之后面对的将是一个比原来更加不符合直觉的数据表）。

不知道这轮改进的动机是什么，如果仅仅是为了解决搜索过程中的一炮三响，似乎没有什么改进的必要。

其实一般来说，自己写的玩具软件比商业软件更不安全

@Vanessa

思源 v1.4.1：

workflowy：

roam research

大纲编辑器都是根据有没有子节点来决定有没有竖线的，现在 v1.4.1 的逻辑好像是下面有同级节点就会产生竖线，这样会搞出很多种比较丑的形状，像下面这张图里的 5 9 7 就跟被列表块孤立了一样，视觉上完全丧失了列表的结构性

这里 2 3 两个节点都没有子级，这根竖线没必要存在

视觉效果极差

在有反链的情况下，标签和锚文本是一回事

roam research 出现之前，标签这个东西就已经存在了，而那个时候的标签是比较简单的。roam research 的标签语法糖完全涵盖了传统标签的功能，而且在反链的操作性上更是比传统标签强太多了，所以准确的说法不是「传递型双链的本质仍然是标签」，而是「标签的功能已经被双链覆盖了」，标签这个词语本身在大纲双链笔记上其实早就该被奥卡姆剃刀淘汰了，只是很多人还舍不得这个老概念，我宁愿把 roam research 的标签语法糖叫做井号双链。

我在使用中遇到过这种情况，有些材料并不知道放在哪个主题，这时使用传递双链会让我卡在选择锚文本上

要么直接选 [[inbox]]，要么直接用多个锚文本，不要把选择的压力留给当下。等这些材料真正需要被用到的时候，自然就知道它该属于哪个主题了。

在使用过程中我还有个疑问，回顾时我经常发现我的这些问题（主题）与另一个问题是某个更大问题的子集，那我的这些反链该如何处理？如何合并这两个问题呢？

在思源里很简单，把那两个页面拖进另一个更大问题的正文里就行了。

靠 css 来实现思源里的标题编号还是有缺陷，因为思源对稍大一点的文档只会动态加载一部分，直接把滚动条翻到下面没法准确计数，而且 SQL 块里的标题块也没法从计数中排除。标题编号涵盖的信息很有用，如果官方支持就好了。

@fangly 可以在教程里直接用一下你提供的例子和截图吗

如果完全采用 roam research 的判断标准，我自己是完全可以接受的。而且我也同意它那套标准比别的标准更能满足大多数人。就看 D 大愿不愿意再改了......

这个还是要结合整套笔记流程来看，不能孤立地看这一步，并且要分类讨论。

比如像 - [[闪电网络]] 文章4（需要重读），它是一个传递型双链，我在 daily notes 里把它记录下来之后，只要整理《闪电网络》的时刻没有来临，我就不会再看到它；过了一段时间我需要整理整篇《闪电网络》了，在反链里看到了 - [[闪电网络]] 文章4（需要重读） 这条反链，它的一级子节点很多，在反链里确实占地方，而且把其它的关联型双链都挤压得不显眼了，但问题是，今天我本来就是来整理这篇《闪电网络》的，在我看到这条反链的一瞬间我就会把它拖进正文去整理，从此它就对反链面板没有影响了。

所以在整个流程中，这条传递型反链就像薛定谔的猫，它存在于反链面板的时候确实很占地方，但这时候我根本看不见它，等我有一天真的看见它了，它就会立马被我从反链面板里移出来，在我这个观察者的视角中，它存在于反链面板的时间只有一瞬间，所以它长一点也就无所谓了。

虽然稍微有点理想化，但我仔细一想，子列表过多的问题从一开始就不是问题，反正传递型双链只是暂时存在于反链面板，查看反链的时候，看到传递型双链直接把它拖进正文就行了，拖进正文之后无论想永久折叠还是想永久展开都可以，就算暂时不做细致的整理，把它放在正文里也比放在反链里更好，最开始让它处于反链里只是为了在 daily notes 里快速记录而已。在彻底整理一篇笔记之后，需要留在反链里的也都是关系型双链，而关系型双链一般不会有子节点。所以最初展示的时候应该是一种宁滥毋缺的原则，至少对传递型双链是这样。

谢谢，这里确实是我思维惯性弄错了。

#2762 里那个例子是为了说明而特意构造的，实际使用的时候，关联型双链一般是存在于一大段文字中，就算在纯粹的大纲型双链笔记中，这样的节点一般也不会再有子节点了。所以 logseq 虽然在功能上会让它展示下级，但实际使用中因为用户一般不会在这里再写一个子节点，所以大多数时候是没什么影响的。

而在想靠双链来达到传递效果的场合里，有时候还是想在锚文本旁边写一点说明文字，比如 - [[闪电网络]] 文章4（需要重读），如果这里也采用「本节点里是否只有一个锚文本」的原则，这种用法就没了。如果有这样的使用习惯，roam research 的判断原则就不太好，就算没有这样的使用习惯，基于上一段的考虑，logseq 的展示方式就算对关联性双链节点有影响，这种影响应该也很小。