好东西，建议官方收编

zotero 有一个高级检索及高级检索结果保存并更新的功能，比笔记软件的数据库还要灵活。论条目管理，zotero 还是要更强。条目归 zotero，笔记归 siyuan。

我初版 tab10 都可以，可能是初次启动时各种计算量太大了。

obsidian 也可以用系统资源管理器管理

可以从卡片内容和卡片存放的角度来思考，双链就是卡片内容之间的关系，标签可以用来对卡片归类存放，现在有了数据库后，数据库也能做这事了，似乎还能做得更好。

因为不能转。标题上面是可以由各种样式的，比如超链接，比如块引用，但文档名不行，你转文档后，行内样式全部丢失，且不可撤回，只能从历史里捞。

图示似乎完全没有高亮了？可能有些误解了。我的意思是，容器块只把它的边框高亮出来。

根据相关插件，把所有块全部廓出来，就得到上图。可见，不同的块，其轮廓本来就是区别开的。我所提议的，就是高亮样式边框化，如下图 word 示例

另外，如下图，如果没做错的，高亮区域就是全部的叶子块了。可以清晰地看出，叶子块，其矩形轮廓，在左右上与包裹它的容器块区隔开了，但上下边框却没有。视觉上感觉顶得太严实了。把现有的方角矩形换成圆角矩形是不是会给人一种能透一口气的感觉？

我想啊，仅限于我的体验啊，只要不嫌开浮窗麻烦，就没这么多事。

还有一个就是你提到的，在 phm 里把故障诊断整全地拖过去，还有之前提到的嫌弃日记式组织的标题与内容脱离，一篇日志下多部分内容无法集中在一个视域里展示。这些问题我也有，对此我有个思路，但还没付诸实践。

在我看来，这些问题都可以归并为内容卡的展示与存放问题。phm 里拖入故障诊断之所以不可行，是因为文档标题不归属正文，它既不是标题快，也不能有行内的引用、加粗等格式。文档块（文档树）与标题块虽然互通，但又没有完全通。我之前特别开帖子反映过，D 大回复说就是不可行。自那我就明白了，把一个主题块制作独立文档置于文档树下是有缺陷的。除了 phm 整个拖入故障诊断之操作麻烦之外，还有标题不能有引用的问题，不然几次移动转化后，引用就丢失了。所以我就在想，似乎，就在 dailynote 里新建文档是不是也不是不行？要新建主题，比如 phm？就单独开一个标题 PHM，然后在需要的地方引用这个标题完事。如果需要整理，就进聚焦。

关于 daily note 标题与内容脱离，一篇日志下多部分内容无法集中在一个视域里展示这个问题，普通的办法还是该用标题等级还得用，然后用插件/挂件在开头处生成本文档的目录。

我现在想说的，还未实践的新想法是：用数据库。卡片不再往文档树放，也不再独立为文档 page，就是 dailynote 中的一个标题，但是把它添加进数据库中，用数据库管理条目，添加日期属性，按日期筛选。

声明：我还没有用过数据库，以上是我云的。但怎么说呢，我觉得道理应该是成立的。如果题主或是他人愿意实践一下呢， 无论成败，还请告诉我一下 🙏 唉，我太懒了，抱歉抱歉。

筛选传递型双链的话应该只能靠肉眼，但可以用独特的方法提高视觉辨识度，比如利用锚文本添加如 @ 一类的特殊符号。

筛选没有整理过的反链，我也想要这个。但是在传递型双链这个情境下不是很需要，因为传递并非引用，当第一次整理结束之后，就应该把传递型引用链接反手右键转为超链接，这才符合引用与超链接的本意不是？

这里面的逻辑是这样的，就没有“分栏”这种东西，分的是块。回车会起一个新块，这个新块会继续执行与旧块水平分布的命令。建立超级块后，水平分布的是超级块。此时回车新起的块位于超级块之内，所以不会再有“分栏”现象。

第三个并列的那个块，可以直接拖到第二个下面，会自动创建超级块

大佬，我有一个小疑惑，Odyssey 主题与 Savor 最大差别似乎就是编辑器和侧栏面板的样式差别，是不是可以考虑把 odyssey 并入 savor，6in1？

大佬你好，我再提一个 。既有反链面板是以文档名为基本条目陈列的，日志在反链面板里呈现为一个个日期。在 daily note 的理念下，笔记大部分都记在日志下，使得 daily note 流程天然比新建文档在反链面板上少一层标题信息。daily note 流程中，一个日志文档本质应是传统笔记方式里诸多文档在管理上的归并，不宜作为笔记内容上的组织单位。希望记在 daily note 下的笔记在反链面板上，能从日期文档名往下细分一层，细到管辖引用块的等级最高的标题那里。当然，没有标题自然无事发生。

曾经有一个挂件 note backlines，它的展示效果就是在有标题时展示标题，只是引用块本身所在的块就不展示了。效果图：

在文档“2”中看的很明显了，其中“第一个标题”和“第三个标题”下都有引用【示例】，“第二个标题”下则没有。另注：“3”是一段普通的文本段落。“1”是一个列表块的父级块。

长处短处都很明显的一个挂件。

--------分割线-----

之前提了一个“用过”的建议，再加上现在发的这个，我开始觉得改动程度还挺大的

就我而言，我需要一种区分，“用过”的区分。即，本页面 A 被页面 B 引用，本 A 的反链面板有 B。当本 A 引用或嵌入了 B 中引 A 的块时，在本 A 的反链面板上给出标记“用过”。

用意是，不希望反链面板只是一次检索展示，不希望每次开反链面板都是一次新检索，希望对检索结果的整理能够有所保留。

我有一个思路：

• 在我看来，一个超级块跟一个列表块是等效的。一个列表块合若干列表项块于一个块，跟一个超级块合若干段落块（没人用超级块合列表吧）于一个块是一样的。

• 但有一点不一样。列表块中，可以在其上建立一个父级节点，写传递型双链或统摄性文字；但超级块不行，它只是圈了起来。

  • 超级块或者说段落块要统摄一部分文字只有用等级标题。
  • 等级标题很不灵活。特别表现在它不能手动控制等级标题的管辖范围。能终止上一个等级标题管辖的只有下一个等级标题。这意味着，文章中间一旦打等级标题，那后面全都要打。
  • 标题是正文的一部分，不是所有的传递型双链文本都适合充作正文
  • 标题意味着正式分割正文，不好随便。

• 曲线解决：仿照列表块，手动创建两个超级块。内超级块是内容。外超级块包裹内超级块，并且在内超级块上方写统摄性文字或者打传递型双链

• 软件需要的功能：当内超级块与其上的传递型双链组成外超级块时，反链面板要能展示内超级块。就像列表块在反链面板里展示自己的子级节点一样。

• 总精神：仿效列表块。

用挂件 query，不会把全文带出来，只展示条目。但是简单的查询语句得出的查询结果只是平等地罗列文档条目，不能反映父子关系。别的我不会了。

类似的，挂件 note view 能更好看地展示，查询结果同 query，也是只展示条目，不能反映父子关系。也许行吧，但我不懂。

我脑测一下：

先复制到 word，用查找替换给每一个~前面加转义符号\，然后再复制到思源里

不想多用一个软件的话，插件市场里有一个“集成编辑环境”，用它以 markdown 格式打开当前文档，这样~就都暴露出来了，接着查找替换，加转义符

有两个迂回解决办法：用浏览器开思源，用浏览器的词典扩展；下载本地词典客户端，用快捷键实现划词查询。

感谢分享。另外建议把“视频笔记插件”写入标题，方便后来人检索查找，不然标题没有，正文没有，日后这帖子就彻底沉了。

就我的理解而言，剪切是文本操作，移动和引用都是块操作。所以在以块为单位的软件里，最好不要用剪切。

有一个代码片段可用，缺点是与若干主题不是那么兼容

/* 大纲块标隐藏样式 /
/ 为大纲块标和折叠按钮调整位置 /
ul.b3-list.b3-list--background [data-subtype="h1"] .b3-list-item__toggle,
ul.b3-list.b3-list--background [data-subtype="h2"] .b3-list-item__toggle,
ul.b3-list.b3-list--background [data-subtype="h3"] .b3-list-item__toggle,
ul.b3-list.b3-list--background [data-subtype="h4"] .b3-list-item__toggle,
ul.b3-list.b3-list--background [data-subtype="h5"] .b3-list-item__toggle,
ul.b3-list.b3-list--background [data-subtype="h6"] .b3-list-item__toggle {
position: relative;
left: 20px;
}
ul.b3-list.b3-list--background [data-subtype="h1"] svg.b3-list-item__graphic,
ul.b3-list.b3-list--background [data-subtype="h2"] svg.b3-list-item__graphic,
ul.b3-list.b3-list--background [data-subtype="h3"] svg.b3-list-item__graphic,
ul.b3-list.b3-list--background [data-subtype="h4"] svg.b3-list-item__graphic,
ul.b3-list.b3-list--background [data-subtype="h5"] svg.b3-list-item__graphic,
ul.b3-list.b3-list--background [data-subtype="h6"] svg.b3-list-item__graphic {
opacity: 0;
position: relative;
left: -20px;
margin: 0 0 0 4px;
transition: all 300ms ease-out;
}
/----------------------/
/ 为大纲块标添加悬停显示效果 /
.b3-list--background .b3-list-item:hover .b3-list-item__graphic.popover__block {
opacity: 1 !important;
}
ul.b3-list.b3-list--background [data-subtype="h1"] svg.b3-list-item__graphic:hover,
ul.b3-list.b3-list--background [data-subtype="h2"] svg.b3-list-item__graphic:hover,
ul.b3-list.b3-list--background [data-subtype="h3"] svg.b3-list-item__graphic:hover,
ul.b3-list.b3-list--background [data-subtype="h4"] svg.b3-list-item__graphic:hover,
ul.b3-list.b3-list--background [data-subtype="h5"] svg.b3-list-item__graphic:hover,
ul.b3-list.b3-list--background [data-subtype="h6"] svg.b3-list-item__graphic:hover {
color: red;
}
/----------------------/
/ 为大纲标题项添加背景过渡效果 */
.b3-list--background .b3-list-item {
transition: all .3s ease-out;
}

作者：Nofood
链接： 啊哈哈哈代码来咯 ~~ 那你们先吃我就不打扰了哈 ~~
来源：链滴
协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

这是不是可以成为该软件的宣传点？我记得还看过一个用虚拟引用辅助阅读《百年孤独》和《红楼梦》的贴。一方面，有标注好的小说资源，可以诱导少部分人下软件；另一方面，如果虚拟引用能嵌入到小说文本中，以超链接形式随着正文合成一个文件导出来，那么标注好的小说资源肯定能压过没有标注的资源，再打上 siyuan 的水印，这肯定能成为一波宣传啊。小说圈应该不算小。

@88250 开发者是不是可以往这方面想想，看看有没有门？

大佬，我又来问了。请问我插入新文献时，生成的页面第一行是“user data”，这个 userdata 是指向本页面最后一个一级标题”user data“的块引用。为什么会创建这个？另外，希望模板参数能增添编辑 editor 和期刊 publication。谢谢 🙏 ！

大佬，我都重启好多次了，仍然提示“Zotero 没有在运行”

大佬你好，我看到视频演示里插入引用是用超链接实现的，那请问将来这里的功能会与另一边的插件功能互通吗？ 思源笔记文献引用插件 siyuan-plugin-citation

具体指的是，有一篇文献 A，我已先用插件把 A 导入笔记，相应地我拥有了一个 A 的页面。现在我在另一处使用本帖的 quicker 也插入了 A 的引用，请问这里 A 的链接有可能直接变成已有的对页面 A 的块引用链接吗？

似乎，文章前半部分链接大部分都是 404

“防止反链丢失”部分，按我的理解，转移引用是 A 处引 B，而后在 B 处把关系转移到 C，它要在 B 处操作。反链丢失，丢的正是 B。所以它应该不能防止反链丢失。至少，在“补救”的意义上不能。

我没用过 notion 及属性视图，就我目前脑测，想向楼主讨教，这个”属性“功能是不是管理”条目“的利器？

好比 zotero 管理文献条目，如果放到 siyuan 里，是不是都不需要建立一个页面，只要在空白行打上文献的作者和标题，然后利用”属性“功能补充其他信息，就能建好一个条目？再利用块引功能写文献内和跨文献的笔记，这不就把 zotero 覆盖了？

甚至除了文献条目，一个知识点也能作属性管理。这就成了知识管理功能的大拓展。

唤起了我以前的记忆，我很久以前也碰到过，不太记得了，似乎像是直接把工作空间放到了 OneDrive 这类同步盘上搞的。

我投赞成票，虽然我自己不是，但我相信一定有许多用户是不需要严格的私密性的，一来是个人防护意识淡漠，二来可能是笔记内容本身并不敏感。提供内置密钥与其说给防护意识淡漠的人以方便，不如说是给内容不敏感的笔记记录以方便——免得给人一种成见：我又不记录多私密的笔记，干嘛要用思源笔记？

所以，在提供内置密钥时，不妨把说明适当夸大点：选择内置密钥几乎默认你放弃私密性。