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

先占楼再看

疑虑 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 的展示方式就算对关联性双链节点有影响，这种影响应该也很小。

我觉得你上面提到的两种方式最主要的区别就第一种主动把文章 2 和文章 4 拆到了两条反链里，第二种是让文章 2 和文章 4 处于同一条反链里。文章 2 和文章 4 都塞在同一个标题块里确实不太利于查看，但是就算是第一种方式，文章 2 下面也分标题 1 和标题 2，如果标题 1 对应的内容太长一样没法直接在反链的那个列表块里看到标题 2 的内容。

所以我还是倾向于改成像 roam research 那样把第一个子级都展开，第一子级太多我觉得不算大问题，现在反链里展示列表块只是相当于做了个默认折叠，真正重要的内容就应该一览无余地展示出来，只要能保证用户可以手动折叠就行了。

但是这个问题的关键还是在于，不管反链具体采用哪种形式，都需要尽快敲定，因为用户的使用方式也需要去适应软件，这个需要 D 大 @88250 尽快想好，哪怕只是口头决定也行，不然大家就不太敢用起来。

还有一点，1.3.5 的这种展示列表块的反链形式只存在于思源这个软件上，它有一个绕不过去的弊端就是缺少舆论背书。哪怕今天有人说这种形式还可以接受，但将来一定会有其它使用习惯不同的人觉得它不好，那个时候又要陷入无休止的争议。但如果采用展开第一层子级的形式，首先它已经被别的软件证明了是实用的，其次将来就算别人有所质疑，只需要说一句「这个设计是跟 roam research 一致的」就可以比较容易地把质疑声挡回去。光从功能上说，每个人都能根据各自不同的使用习惯为每种设计列出一些优缺点，但是有些设计在舆论上就是比别的设计更加站得住脚，这个是思源非常缺乏的。

+1

Siyuan Note - The best unoffice Yuque desktop app

+1，我 1.3.1 也遇到了这个，而且我的日志跟楼主一样

在文档底部靠 SQL 块来代替反链，还是只能应对层级比较少的列表，如果列表层级比较多，整个 SQL 块的展示就会很长而且手动去折叠不方便，所以还是需要官方的反链面板加入我在这里提到的列表层级折叠规则，用一句话简单总结就是「含有锚文本的列表项下面的子项最多只展示一级就够了，更深的层级默认折叠起来」。思源早期曾经做过多层级的反链，虽然当时的展示太冗余，但是现在有了明确的层级选择规则，优化出来应该不难。

如果官方反链面板像上面说的那样优化了，那么完全可以期待反链面板也具备拖动能力或是一键移到正文，不需要再借助麻烦的浮窗拖动。总的来说关于层级的优化才是最核心的，现在无论是从侧栏反链面板弄出浮窗还是从 SQL 块上弄出浮窗，基本都需要再 zoom out 一次甚至两次才能拖动，就是因为层级不合适。所以浮窗自身的优化我感觉不重要，现在就算再优化浮窗也起不到什么提升效果。

总结一下，可以优化的点主要有：

• 列表块的反链层级展示规则
• 反链面板最好自身就具备拖动功能，或是能够一键发送到正文，总之把反链区的内容移到正文的能力一定要有。如果做的是拖动，那么锚文本所在的那一行在反链面板里应该显示列表项块的块标，让它可以带着子节点拖动出来。
• 有一件事情是 roam research 也没有做好的：已经在反链面板出现过的子节点如果提到了当前 page 的名称，那个节点会在提及面板再出现一遍。如果这一点也能优化就最好不过了。

上面提到这些优化特性都不会影响到不需要这些特性的人，但是思源之前的几次重大更新似乎已经把保守派用户弄成惊弓之鸟了，右翼有点过分保守了，所以这方面的优化最好是静默进行，先把生米煮成熟饭

主题最好是自己写，避免被卡脖子

2、我的日记设置是 /日记/{{now | date "2006-01-02"}}，如果照这个不能复现的话就不清楚了

3、简单一点就是让右键也呼出块标菜单，精致一点就是让用户自己为右击块标绑定事件

思源的反链是需要认真优化一波，如果把双链笔记软件比做一个人，那反链就像腰部，整个身体的发力都依赖于它

另外，我不是 d 大，这位才是 d 大： @88250

我只是个普通用户

按照大纲双链笔记的流程，一开始在日记文件里写下「判断标准」这部分内容的时候，就应该当场立即用某种方式把它传递给「SOP」这个文档，这个传递方式就是双链：

# 2021-07-03.sy

- [[SOP]]
  - 几个好课题的判断标准
    - balabala
    - kalakala
    - xxxxx

将来集中整理 SOP 这个文档的时候，从反链里可以直接把 - [[SOP]] 和它下方的所有列表项拖进正文然后慢慢整理，这种流程比一开始不加双链事后再去 SOP 这个文档里引用要稳妥得多。

在思源里实践不了这个流程是因为打开 SOP 这个文档的时候，看到的反链只有以下信息：

▼ 2021-07-03.sy
  ¶ SOP

这个反链只显示了一个段落块，- [[SOP]] 下级的内容全都没有直接展示。如果反链面板优化一下展示方式和可操作性，就可以实践上面说到的流程了。所以问题依然是功能需要优化。

要解决第一个问题至少在思路上并不难。比如在做记录的时候完全使用新文档就是一种比较流畅的方式，反正这些文档在将来可以转换为文档内的标题块。但是思源的功能暂时还支撑不起这种工作流，因为如果想要让这些新文档不至于变成将来找不到的孤立文档，就一定要有一个「方便易用的文档级多级标签」，并且标签面板里列出的文档块要能够方便地拖进正文。

解决第一个问题的第二个思路就是不使用新文档，新增内容都添加到已有文档里。这种工作流靠思源现有的功能也无法完成，需要先把 notion 的内容块移动功能学过来。在做记录的时候，无论当前文档是什么文档，都可以在原地写下来，然后把内容块用快捷键直接发送到指定文档里。而且思源完全可以进一步拓宽这个功能，notion 只能把内容块发送到某个文档末尾，思源在这里完全可以做成把内容块发送到任何一个块的下方，就像 roam research 的 ctrl + shift + 9 一样，只要文档块在搜索过程中置顶就行了，并且思源还有别名功能，可以进一步优化这个搜索步骤。

你的思路方向没有错，现在的问题在于已有功能还撑不起思路的实践。上面两种功能我个人觉得都该优化一下。

第二个问题，没太看懂描述，能用图说明吗

好问题。尽管不易察觉，但这两种方式有极其巨大的区别。

假设今天我逛了一下 logseq 论坛，看到有人说新版本通过修改 :ui/show-empty-bullets? 变量可以显示或隐藏内容为空的 bullets，于是我想把这个配置方法在笔记软件里记录下来。

然后我打开 logseq 做记录，步骤如下：

1. 打开或转到 logseq 这个软件，如果当前页面不是 daily notes 就再按一下快捷键跳转到 daily notes 页面

2. 在 daily notes 的第一行写下：

   - [[logseq/配置]]
     - `:ui/show-empty-bullets?` 变量：显示或隐藏内容为空的 bullets
   

3. 记录结束。去做别的事。

如果使用 typora，步骤如下：

1. 为了最快捷地打开 logseq - 配置.md 这个文件，当然是要好好利用各种搜索型效率软件了，于是我在 utools 里搜索 logseq 配置，结果发现我并没有这个文件

   • 这个时候第 1 个差别就已经体现出来了，在 logseq 里，我永远不用回忆 logseq/配置 这个页面是不是已经存在，直接在 daily notes 的第一行开写就行了

2. 搜索未果，我开始考虑换个关键词搜索，万一我以前创建的文件名叫 logseq - config.md 呢？换了几个关键词搜索，发现我以前真的没做过这方面的记录

   • 第 2 个差别出现了，在 logseq 里，我不需要考虑自己之前是不是已经用别的名字创建过 logseq/config ，这种文件，我只需要直接在第一行写下 - [[logseq/配置]] 就行了，别的什么都不用考虑

   • 第 3 个差别：就算我以前已经有了 logseq/config 这个 page，那也不需要管它，因为 logseq/配置 和 logseq/config 这两个页面一定会在 logseq 这个父页面下共同展示，我可以在将来合并它们

3. 既然以前没有对应的 md 文件，那我就创建它吧。创建一个新的 md 文件虽然人人都会，但是我在创建的时候就需要给它在文件系统上安排一个具体的位置，我是把它放在 软件使用 文件夹下还是放在 知识管理 文件夹下？

   • 第 4 个差别：在 logseq 里没有烦人的新建文件流程，就算我根本不对 md 文件分类，新建文件这个步骤还是烦人

4. 终于新建好了 logseq - 配置.md 这个文件，但是我忘了刚才想记录的是什么

   • 第 5 个差别：用 logseq 记录，到达路径很短，心智负担为零；用 typora 记录，到达路径很长，心智负担巨大

5. 查看系统剪贴板，回想起了要记录的东西，开始记录

6. 记录完毕，我开始了每日固定的读文献时间。30 分钟之后，我有一条突发的阅读心得无论如果都想赶紧记录下来，于是我唤出了 utools，再次重走上面的曲折心路历程。

   • 第 6 个差别：如果是用 logseq 记录，我只需要再次在 daily notes 页面的第一行写下：

     - [[文献/文献名]]
       - 这个思路真是妙啊
     - [[logseq/配置]]
       - `:ui/show-empty-bullets?` 变量：显示或隐藏内容为空的 bullets
     

所以，这两种方式看似差不多，实际上是天壤之别。笔记的核心首先是记录，而 Conor 流程把使用者在记录时的心智负担降到了接近于 0 的水平，这种流畅无压的记录方式能极大促进一个人记录更多的东西。

我这里说的还仅仅是记录阶段，后面的阶段差距更大。

我们讨论的是"究竟选择那种方式会比较好?" 是完全无压力但后续整理麻烦的 Dailynote 还是选择稍微有点压力但是后续整理会轻松点的方法? 我也不知道, 这个心智压力若是实在想完全没有, 那就选择 DN, 若是想方便之后整理还是接受点心智压力就选其他方法, 感觉这个比较随人, 但我已经习惯了开 portal 了

这段总结得很到位，在认清两种方式的差异之后，剩下的就是个人选择。不过这个选择大多数人不需要纠结，因为不用 remnote 这个软件就实践不了 remnote 的方法，我真正担心的是这两种方式都离思源比较远。

但 DN 中已有很多内容的时候, conor 也会使用 zoom in 来消除其他文本的干扰的对吧?(这里我不咋清楚, 所以打了个问号)

这个不需要，新的想法永远写在第一行就好了。

好的，巩固稳定性最重要，这是第一优先 (ง •̀_•́)ง

之前还有个想法忘了提，notion 有一个非常实用的功能也能很好地应对快速记录这个场景，就是 block 菜单里的移动功能，可以把内容块发送到选定的文档里面（搜索过滤），将来可以学一学：

其实无论是用 rem tag 来做分离还是直接用 portal 记录，都是在记录的时候提前考虑整理问题。普通大纲双链笔记软件那种混杂的反链强制性地阻止了这种提前考虑，这对于快速记录来说其实反而是好事，因为把整理的负担推给了未来、所以当下能做到零压力记录。未来真的要用到某些笔记的时候，整理笔记的困难跟完成一个任务要面临的众多真正困难一比其实不算什么。

我是以这样的模型来思考这个问题：对一个人来说，整理笔记的心智负担并不是完全恒定的，比如 Conor 流程把整理的困难完全抛给了未来、以达到当下的完全无压，它的心智负担大约是当下 0 未来 40；remnote 可以稍微把整理的困难分一点到当下，同时大大降低未来的整理困难，它的心智负担大约是当下 5 未来 25；而传统文件夹笔记一般都需要在记录时就把整理方式考虑好，而且未来依然需要整理，它的心智负担大约是当下 50 未来 50。

粗略来说我觉得 remnote 更先进，但是如果「未来」永远不来，Conor 流程里的心智负担就永远是 0。

能帮忙填下这个关于双链笔记的问卷吗 😋 ：https://www.yuque.com/forms/share/cee13285-b07c-4adb-818c-809b9ba2497a

@88250 看来亟需优化，以挽留楼上这样的用户 🌚👆

其实简单来说，就是以 daily notes 为核心，做到流畅无压记录，然后靠反链的高度可操作性实现后期整理。

- [[链滴]]
  - 反馈关于思源笔记的意见可以上链滴社区发帖
  - 链滴社区现在用的还是 Vditor 编辑器

如果在 daily notes 里像上面这样记录，就完全没有必要特地去新建或是打开名叫 链滴 的页面，直接在这里记录就好了，将来打开 链滴 这个页面就可以在反链里看到所有跟它有关的信息，相当于通过双链来传递内容，那些反链其实就等同于 链滴 这个页面的正文。

虽然我之后的每天都会在 daily notes 里记录一些跟 链滴 相关的内容，但是我根本没有必要去整理 链滴 的反链，我只需要在心里知道「这个东西将来可以方便地整理就行了」。直到将来某一天我需要写一篇介绍 链滴 的文章，我才有必要去整理，这个时候直接把 链滴 这个页面的反链里的所有内容向上拖进正文，然后靠大纲编辑器的编辑能力来组织正文，最后输出就行。

这个过程没有任何的心智负担，记录的时候只管记录、不需要考虑整理的事，等真正有了应用需求的时候整理起来也很方便。

另外，roam research 有一个合并页面的功能，能进一步降低心智负担。因为 [[链滴]] 和 [[黑客派]] 是同义词，在 daily notes 里思考该用哪个词也会造成心智负担，可是在 roam research 里不需要担心这些，因为 [[链滴]] 和 [[黑客派]] 这两个页面将来是可以直接拼接合并的，所以前期只管记录就好了。这样一来，用户在做记录时的心智负担几乎是零。

还有一些细节没说到，但大致就是这样。

在文件树上点击新建的时候可以直接进入编辑区，因为这个时候新文件的位置很确定了，但是 Ctrl+N 还是需要展示一下新建窗口来让人知道新文档在哪