对第一个问题我好像没表述清楚 😂 ，默认展示内容我觉得足够多了吧，再多就有点占用反链面板的空间了

我想问的是，1.3.6 中不点击上下文按钮的时候是：

不自动换行：

还是自动换行：

我希望是后者，也就是自动换行，或者单独有个自动换行的按钮（该按钮要和现在的上下文按钮一样点了一次后能保持状态），总的来说，就是 1.3.6 中应该要可以实现 不展现子级 + 自动换行 这种展现形式

有两个问题想再问一下 D 大

• 之前的上下文按钮的功能相当于自动换行，那么 1.3.6 中，不点击上下文按钮的时候是自动换行的还是没有自动换行的？个人希望是自动换行的，因为在侧栏宽度小，不自动换行看不到啥东西，如果 1.3.6 是默认不自动换行的话，我想要不展现子级 + 自动换行，在 1.3.6 中就无法实现了，而由于关联型双链占了大多数，因此不展现子级 + 自动换行在实际场景中应该是最常见的了
• 是否有可能完全按照 roam research 的思路实现？即检测该节点的内容是否是只有一个块引用，然后根据此决定反链面板的展现策略

因为这些内容会影响工作流，所以我想先问问清楚

大佬您在 Issue #2762 · siyuan-note/siyuan 中对于传递型双链和关联型双链的一些描述好像有点不太准确。您觉得两者的区别在于有无上级节点，但我觉得两者本质区别在于该节点除了双链锚文本之外有没有其他非双链的内容，如果是单独的双链锚文本即 - [[bar]]，就是传递型双链，如果有其他内容比如 - 3-[[bar]] 就是关联型双链，因为事实上，我觉得传递型双链完全也可以有上级结点，比如我的 daily note 里有一个顶级节点是学习，然后下面是关于学习的内容，我在这个顶级节点之下再进行内容传递，关联型双链完全也可以没有上级结点，如同我前面发的方法 1 一样。

我在 roam research 中看了一下，比如有一个页面是这样的：

这个[[Roam meetup]]上面也没有上级节点，查看它的反链，可以看到也是折叠了，没有展现子列表：

而像这个，有上级节点：

它的反链中还是展现了子列表：

所以，roam research 的具体实现中与您在 Issue #2762 · siyuan-note/siyuan 所描述的原则有矛盾，他们并不是按照有无上级节点的原则展现双链的

所以，事实上，对于关联型双链，思源之前的(1.3.4 之前)的展现内容和 roam research 的展现内容是一样的，只需要把块标从段落块换成列表项就好，不需要展现子级内容

因此，按照 roam research 进行设计的话，应该是这样：

• 该节点的内容除了块引用之外还有其他内容的话，不展现子列表，或者在反链面板中默认折叠，也就是说和 1.3.4 之前的版本差不多，只是把块标从段落块换成列表项就好
• 该节点的内容只有一个块引用，没有其他内容时，展现子列表，也就是按照 1.3.6 的方法

@88250 D 大，您可以看一下，我觉得按照 roam research 的方案来设计更加科学一点，您现在的设计是按照 logseq 做的，个人认为还是有不少差距的。从我的体验以及我所观察到的 roam research 用户的使用方式来说，在单个笔记库内，关联型双链在数量上远多于传递型双链，因为在正文中会有大量的关联型双链，现在改版之后，对于关联型双链的体验还不如改版前的。

还有个类似的问题，我在代码块中粘贴内容后，也会回到代码块开头

这地方只显示第一级列表项，还是把该列表项所有内容都显示出来，我觉得是不是还要再考虑下，按图片中这种做法的话，在实际场景下，每个列表项的内容都非常多，这样一展开上下文，整个反链面板就爆炸了，而且这样可读性也不高，把父项和子项连在一起看着会很奇怪。

我觉得，像这个图片中，只显示第一级的 1 就好，子结点上的 11 不要附上去

图片中的这个设计，基本等价于 Issue #2762 · siyuan-note/siyuan 中葫芦笔记的实现方式，并不是最好的设计，会有比较大的反链面板不可用的风险。按照 roam research 和 logseq 的做法的话是只显示第一级的 1。

顺带问一下，既然修改了上下文按钮的功能，那么 1.3.6 的反链面板在没有按上下文按钮的时候呈现的内容，是 1.3.5 时按了按钮还是没按按钮时呈现的内容呢，个人希望是前者，像我现在每天第一次打开反链面板的第一件事就是点击上下文按钮，因为不开的话，在侧栏的反链面板每一项显示的内容确实有点太少了

目前的形式有一个好处，如果原先父结点折叠的话，我在反链当中可以将鼠标悬浮在列表块上直接查看被折叠的完整列表块，而如果改成展开第一子级的形式的话，就没那么容易了，我只能悬浮在父结点上，然后展开节点，这也是思源的反链面板的限制所在，毕竟和其他软件的反链面板形式差别还是很大的，灵活性差了很多，我觉得现在的引用块悬浮窗都比反链面板灵活很多。

还有我有不少笔记是这种形式的：

第一级子结点全部是图片，如果下面有十几个节点的话，这时候在反链面板中就会连续显示十几个 image.png，这是一个巨大的灾难。

不过这些问题都不算太大，只要 D 大把形式最终确定下来，我跟着改或者保持原状就好，就等着 D 大发话了

我想探讨一个问题：

假设这样一个场景，我目前正在研究共识协议优化与闪电网络等主题，某一天，我看到了一篇关于 PBFT 协议的共识协议优化的文章，之后看了一篇关于闪电网络的文章，然后又看了一篇关于 PoW 协议的共识协议优化文章，最后又看了一篇关于闪电网络的文章

方法 1

这时候，我的 daily note 可以是这样的，不把双链锚文本单独作为一个父结点，而是在父结点后贴上双链，同样能达到传递的功能，并且对同一篇文章可以一次传递到多个文档，这里称为方法 1，如图：

这是闪电网络这个文档的反链面板，目前的形态不错，足够使用：

方法 2

也可以是这样的，按照典型传递型双链的方法组织，锚文本单独作为父结点，我所理解的形态是这样的：

这是闪电网络这个文档的反链面板：

这时候这个反链面板就存在问题了，我们和 logseq 中的反链面板进行对比：

可以看到，思源中是显示锚文本列表项下的列表块，这样一坨的列表块，实际上等价于只显示第一个列表项，也就是只有第一篇文章的内容，而第二篇文章是看不到的

此时就面临一个决策，思源现在的反链面板对列表的展示是否需要进一步修改，也就是说需不需要进一步把列表块拆分成列表项，展示该列表块的所有的第一级列表项，完全变成类似 logseq、roam research 那样？

如果不修改，保持现在的情况，对于习惯于方法 1 的用户（比如我）来说，是有利的，对于习惯于方法 2 的用户来说会不利，信息量少了一些

而如果修改的话，对于习惯于方法 2 的用户来说会有利，而对于习惯于方法 1 的用户来说，可能会导致反链面板不可用，因为对于一篇文章，我的笔记可能非常长，第一级内容就有很多很多，导致下面这种情况，占据了整个面板：

虽然目前的形态对我来说是有利的，但我觉得还是要讨论清楚，不然如果以后修改的话，我的反链面板会变得不可用，我得立刻修改我的 daily note 形式

总结一下，两个问题：

• 方法 1 和方法 2 是否都可行，还是说哪种方法会有问题
• 思源现在的反链面板对列表的展示是否需要进一步修改，也就是说需不需要进一步把列表块拆分成列表项，展示该列表块的所有的第一级列表项，完全变成类似 logseq、roam research 那样
  • 个人倾向于展现形式保持现状(1.3.5)，对于使用方法 1 的用户来说，完美，没问题，对于使用方法 2 的用户来说，信息量少了一些，但还是具有可用性；但如果修改了，对于使用方法 1 的用户来说可能会带来灾难性的影响

我现在是 1.3.5-alpha4，貌似这个 bug 还没有修复

我整体使用方法是：大部分笔记靠 daily note 反链进行组织；等到有些内容整理得比较多了，我想得比较成熟了，有非常清晰的树状结构了，这时才会自顶向下按照文档树进行组织

还有我大纲列表用得非常多，对层级的反链展示比较敏感。

我说的上下文和 Issue #2762 · siyuan-note/siyuan 里面说的差不多，并不是对块的引用是错误的，而是现在思源反链上下文对列表的展现形式有较大的问题，目前 daily note 工作流必须靠悬浮窗 + 点面包屑来实现，等 D 大这个 issue 解决之后，上下文问题基本解决了。

我这里面包屑的作用主要有两个：

1.看上下文，知道现在处于哪个层级，尤其是 daily note 中的引用

2.点击面包屑切换层级

还有你所举的这个例子，我觉得大部分人肯定引用 某概念，而不是 总结，引用 总结 在我看来是一件很奇怪的事情

你认为 sql 这里的额外步骤是属于习惯问题，我认为取消这些额外步骤，也就是说直接能够编辑、复制，对于不需要的人来说没有影响，对于需要的人来说增加便利性，取消这些额外步骤我觉得只有好处没有坏处。

好耶！

那这几种形式各自的作用是什么呢，D 大啥时候有空可以简单讲讲您的设计思路么？尤其是反链面板和引用块悬浮窗，这两个我感觉定位差不多，如果说 D 大改进了反链面板，引用块悬浮窗也应当要跟着改，两者在展现形式上的需求应该是差不多的。

还有反链面板无法直接进行复制、编辑等操作，需要通过悬浮窗进行，体验上和其他大纲型双链软件比还是有一些差距。

@88250 D 大，您是不是漏看了我的这个 bug😂

对于第一点，只要习惯在文档树中点击时，始终点击文档图标左边的位置，使用体验和文件夹模式是一样的，这时候有子文档的会展开子文档，如果是末端文档会自动打开，和之前文件夹模式时的一样。当然和语雀一样加一个空结点对于习惯文件夹模式的用户来说体验会更好一些。

对于第二点，不同的人使用方式和体验不同，不能一概而论，如果是像你说的默认只读对我的使用体验影响很大。如果 d 大真要加，希望是默认只读或编辑都可以。

对于第三点，同上，默认只读这个事对不同的用户不能一概而论，而且目前几乎所有笔记软件和编辑器软件也都是默认编辑模式的。如果我有一个灵感想写，我还要点击按钮后才能编辑，这显然严重影响编辑体验，也是违背双链笔记的 daily note 思想的，当然，有的用户确实习惯不同，但至少应该可以让用户选择默认只读或默认编辑。对于加密功能，现在的锁屏功能和你说的加密功能差不多，都是需要密码才能打开思源。

对于第五点，你不想要编辑为什么要单击它呢，不能说因为有的用户会单击误触所以取消掉单击编辑功能啊，那所有的单击功能都得取消了，不管怎样都得给单击动作赋予含义的，就算单击后不是编辑也会有其他功能的。这部分和你前面说的默认只读也有关联，你要查看内容查看就完事了，不用到处点鼠标。我以前也和你一样看文章时喜欢到处点，然后每次写 word、excel 的时候点着点着一不小心就会把内容拖拽到别的地方，当场发现还好，撤销就行，有时候最后才发现，这时候调整就比较麻烦，所以后来我就改掉了这个习惯。

我不是这个意思，你说的这个文档块引用如果思源都不支持的话，思源算啥双链笔记呀

我说的是，比如下面这个：

我把这个标题拖拽到文档树后，这个块引用就失效了

+1，我觉得放面包屑有必要

我觉得可以把现阶段思源里面 sql 查询的嵌入块 和 其他双链笔记的底部反链对应（现在思源的反链面板的功能还有些逊色），两者都可以用来筛选内容块

个人认为这个功能挺重要的

因为现在思源的分享功能不完善，想把一篇较长的文章分享给别人目前最好的方法就是导出 pdf，然而 pdf 没有目录，思源里面大部分主题对于标题的不同层级也没有非常明确的区别，也没有对标题的自动标号，所以这样一份 pdf 可以说可读性是非常差的，尤其在文章比较长的时候

服务提供者不知道密钥的，密钥在本地又不会上传到云端，密钥生成也是基于你自己填写的密码，在本地离线生成

如果担心密钥被传到云端了，可以自己监控出口数据包，如果发现密钥被上传到云端了，只要有一个人能发出证据，思源口碑马上崩塌

刚刚群主池鱼大佬给了方案，这样应该可行：

代码高亮的逻辑确实有一点问题，如下图，函数名被修改后就没有高亮了，我得在其他地方编辑一下才会恢复高亮：

我什么时候把问题隐隐提到技术上了？可能我的表述让你产生了误解，我就是从用户角度来说的。

除了坚果云看不了更新日志之外没有任何功能因为 id 化而受到实质影响，然而坚果云看更新日志这本身就不属于思源的功能。

你说思源哪个功能需求现在因为 id 化而不方便？

正如上方反馈,面对全是 Id 数字的文件确实让很多"深度使用"需求的场景变得非常不方便,甚至变得无法实现.

举个例子？我真没看出来哪个功能在文档名 id 化后无法实现

有什么功能需求就说需求，别把所有问题都怪到文档名 id 化上

我认为，目前文档名 id 化带来的唯一负面影响就是在坚果云中看不到是什么文件修改了（至于无法在资源管理器中管理文件，等到 d 大把思源内部的文件树功能优化好，资源管理器就完全用不到了，文件树完全可以替代资源管理器。至于想要把思源源文件分享给别人，肯定是在思源内部查看，编辑好，然后文件树中打开-打开文件位置，不可能有人从 C 盘根目录一步一步打开文件夹找文件吧，显然是思源内部定位后再定位源文件更快）

因此，用户真实的需求是能查看到文件修改的历史记录，用户默认的查看方法是通过坚果云查看，现在通过坚果云查看不了了，用户就觉得 id 化这个决定是不好的。

所以用户抱怨的根本不是文档名 id 化，而是无法查看文件修改的历史记录

然而事实上，要查看文件修改的历史记录最好的方法是通过坚果云吗？这种依赖第三方软件的方法肯定是无法作为最佳解决方案的。我认为更好的解决方案是 d 大开发查看文件历史修改记录的功能。

因此大家不应该反对文档 id 化，这是没有意义的，而应该让 d 大开发查看文件历史修改记录的功能。

包括在文档内链接跳转到另一个文档，也不会自动定位到那个文档

不过现在的 sql 貌似也可以差不多实现这个功能

但是过滤面板的好处是可以提供关键词让我们自己选，用 sql 的话需要自己想搜什么关键词，而且因为要检索的是链接，所以还要找到对应文档块的 id，体验上差了不少。但是用 sql 也有优点，就是在灵活性上强不少，不仅可以过滤链接还可以通过普通的文本进行过滤。但过滤面板对于一个双链笔记来说我觉得还是必不可少的。

为什么你要到资源管理器中查看思源的文件？你也不可能在资源管理器中找文件打开文件呀，都是直接在思源软件里操作的

本地文件名改成 id 并不会影响正常使用

我在 1.2.31 中测试了在本地 json 文件中直接修改文档块 id 看起来是有效的，能满足需求，不过貌似需要关闭笔记本再打开才行，不然会有 bug。刚刚又对 1.2.5 测试了也是可以的。

但是不知道直接在本地 json 文件中直接修改块 id 这种做法会不会造成什么隐性的 bug 之类的？

是啊，我直接上图吧，您可以看看这个正不正常：

移动，把该文档的全部子文档移动到别的地方

不对呀，我对这篇文档的引用全都是引用文档块的

奇怪高亮.zip

里面的 奇怪高亮.sy 我这里看是这样的：

我有一个疑问想请教一下：

针对你所举的 longseq/资料这个例子

conor 的流程是先打[[longseq/资料]]然后写具体内容

那如果对于传统的没有双链的普通笔记软件甚至是直接用 typora 编辑器，我可以是搜索 longseq/资料这个文档，然后把新内容写在最上面，看起来在功能上和体验上与 conor 相比的没有太大区别

所以 conor 这个方法的优越性在什么地方呢，想请教一下