当前对于嵌入块的处理是采用了 SQL 语句搜索特定块的方式,但是我认为 SQL 搜索和嵌入块其实是不同的东西,当前这样处理也会出现很多问题,比如下面的很多帖子(我自己也是老用户了,使用了非常多的嵌入块,同时也使用过其他软件)。这些帖子的问题大致分两类,一类是关于嵌入块的;一类是关于 SQL 查询块的。
-
关于嵌入块
-
关于 SQL 查询块
下面主要想讨论一下嵌入块和 SQL 查询使用时的逻辑不同,以及由此带来的功能也应当不同。
嵌入块逻辑
由于其特性,嵌入块的使用场景一般是:该块对于两个父块都很重要,同时内容具有强关联(一模一样),下面是举例:
- 文档块:春秋战国
- ……
- 嵌入块:秦朝的诞生(战国的结束)
- 文档块:秦朝
- 秦朝的基本特点
- 秦朝的发展:
- 秦朝的诞生(战国的结束)
- 秦朝的兴盛
- 秦朝的灭亡(汉朝的诞生)
- 文档块:汉朝
- ……
- 嵌入块:秦朝的灭亡(汉朝的诞生)
所以由于这两个特性(对被嵌入文章的重要性和对所在原文的强关联),块嵌入在两个文档块之间建立了强逻辑关联(甚至强于块引用),而反链恰恰是这一逻辑关联的最好体现。
==因此我认为嵌入块主要应当提供以下几点特性==(父级结构反而没必要显示):
- 提供反链(很重要)
- 提供直接的编辑体验(这样更顺滑,但是浮窗也可以顶顶)
- 提供页内搜索(我个人很少用,因为都是小文档,只是逻辑上应当有)
其他软件的做法
其他软件针对嵌入块(或类似概念)的做法
特性 | Logseq | Remnote | RoamEdit |
---|---|---|---|
反链 | ✅ | ✅ | ✅ |
直接编辑 | ✅ | ✅ | ✅ |
页内搜索 | ❌ | ✅ | ❌ |
显示父级结构 | ❌ | 悬浮显示 | ❌ |
SQL 块逻辑
SQL 块其实是起到了聚合内容的作用,并没有和原文产生强关联,这也是和嵌入块最不同的地方。大家往往想知道这个内容:
- 出现了多少次
- 在哪里出现了(因此这个帖子里有很多附和的 SQL 查询块显示内容的层级)
而并不关心:
- 页内搜索(因为 SQL 本来就是搜索)
- 是否有反向链接
==所以我认为 SQL 块可以提供以下特性==:
- 提供面包屑显示(比较重要)
- 直接编辑(感觉这个对于编辑器顺滑很重要,而且误操作可能性真的不大)
其他软件的做法
其他软件针对搜索块相关概念的做法:
特性 | Logseq | Remnote | RoamEdit |
---|---|---|---|
显示父级结构 | ✅ | ✅ | ❌ |
直接编辑 | ✅ |
✅ | ✅ |
页内搜索 | ❌ |
✅ |
❌ |
针对思源的建议
目前思源不对嵌入块提供反链(以及其他特性)的原因是:反链是 SQL 查询的一种,因此不提供反链;这也就是说如果想让嵌入块提供反链,将要开发一种新的块。
我很能理解 D 大和 V 姐的开发压力,也非常感谢二位开发这么好的软件来帮助我们管理知识。但是因为双链笔记中,反链是非常重要的一环,也是要求符合思考逻辑的一环,所以我还是想说,这里的逻辑应当是:嵌入块逻辑上应当有反链(或其他特性),只不过可能开发难度较大,所以还没有;而不是:嵌入块就是 SQL 的一种。。。所以希望能开发一下其中比较重要的特性。。
在这里也非常真诚地邀请大家来讨论这个问题,以便思源更好的发展。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于