如题,在反向链接里,没有办法 区分链接到主题和链接到子标题以及链接到文件里的块
所有链接都是一样的重要程度
如 [[主题]] [[主题|标题1]]
这些都是一样的重要程度
简单结论是, 能区分 “链接到主题 vs 链接到子节点”,
但是很难拿自带反链面板把这信息表示清楚, 理由是, 元数据利用起来不那么方便, 以及反链面板不好轻易修改
元数据方面, 控制台查 app.metadataCache.resolvedLinks
可以看到, 实际上 Ob 解析出来的笔记之间互链计数, 它没考虑链接到小标题和 block-id 等细节
而另一个携带了链接小标题和别名的元数据 app.metadataCache.getLinks()
, 它不是专门按 “笔记名字” 来汇总的
难搞的另一个原因是, Ob 自带面板似乎是没法自由扩展的, 很难补充新信息进去
所以回到这需求, 本质还是 “为符合条件的笔记做精细统计”,
其中, 条件是当前笔记的反链笔记,
精细统计的是链接过来的次数, 链接过来的具体指向位置
目前个人觉得, 还是用 dv 合适干这事
```dataviewjs
const noteName = dv.current().file.name;
const allLinks = await dv.current().file.inlinks;
let info = [];
allLinks.forEach(async link => {
if (link.path.split('/').pop().slice(0, -3) === noteName) {
return;
}
const linkMetadata = app.metadataCache.getLinks()[link.path];
// 从 content 里统计
// 命中 [[currentPageName]] 的次数
// 命中 [[currentPageName#sub]]
// 命中 [[currentPageName#^blockid]] 的次数
const link2fullnote = linkMetadata.filter(l => l.link.endsWith('.md') ? l.link.slice(0, -3) === noteName : l.link === noteName).length;
const link2anchor = linkMetadata.filter(l => l.link.startsWith(noteName+'#')).length;
const link2blockid = linkMetadata.filter(l => l.link.startsWith(noteName+'#^')).length;
info.push([
link,
link2fullnote+link2anchor,
link2fullnote,
link2anchor-link2blockid,
link2blockid,
])
});
info.sort((a, b) => b[1] - a[1]);
// 输出结果
dv.table(['反链笔记', '链接总次数', '链接到完整笔记', '链接到heading', '链接到blockid'], info)
```
效果如下 (文件路径细节挺复杂的, 可能有没考虑到的地方)
具体怎么排序, 那就看需要了
大佬有心了!
感觉ob作为双链软件,似乎对链接并不是很上心
链接没做区分,内容移动链接也容易断,官方的移动内容插件在移动内容的时候也不维护链接
我其实也没搞明白这些链接细节, 如果以后弄懂一点了, 我再回来补充吧
感觉ob作为双链软件,似乎对链接并不是很上心
回到楼主具体这个评论, 我觉得自己能跟楼主在一些问题上有共识, 包括:
- 链接到笔记自身或小标题, 蕴含着不同信息, 某些场景里其中的区别是有意义的
- 链接移动时最好足够健壮, 能智能应对意外局面, 出问题了及时报警, 要做到别让用户操作时心有疑虑
- 笔记重组功能应该给个预览, 让用户能事先看到将要发生什么
以上这些, 都是一个好软件应该做到的
但是从另一方面考虑:
如果官方真把 “链接到笔记自身, 小标题, 块id” 拿三种符号表达出来, 把这认知成本直接甩给广泛用户, 这是否真能被人好评, 我其实是怀疑的
而这个链接的设计以及对复杂场景的乏力, 则依然是几个经典 “权衡” 的结果:
- 数据搁在强格式约束的数据库里 vs 数据搁在半结构化 md 里
- 解读数据依赖外界规范 (schema) vs 数据是自明的 (自我描述的)
- 所有修改都由软件自身操持 vs 笔记是公开的, 可同时被外界工具协助修改
事实上 Obsidian 在所有取舍中, 都选了后者
对于链接也是, Obsidian 就不想让用户有 “链接 id” 的概念, 就希望 “笔记名叫啥, 链接就叫啥” 这么简单用起来
- 链接尽量要: 简单好懂, 易创建, 易协同修改, 对用户的错误书写宽容
- 与此同时, 牺牲了链接的: 抗变动的稳定性, 搭建高级链接结构的潜力
这算是替 Ob 的 “缺陷” 辩护吗?
嗯, 一部分算吧,
另一部分的目的是, 说明这种设计的优势, 我们好尽量设法利用这些优势,
至于劣势, 我自然也是同意楼主的
官方的移动内容插件在移动内容的时候也不维护链接
我拿几个笔记相互链接到各自的 笔记自身, 小标题, 外加另一个旁观者笔记链接到所有的小标题, 然后以官方的 “笔记重组” 试了试各种重组, 简单场景下似乎还挺智能的, 没出啥乱子
但如果场景复杂了, 要出问题了还真不好说, 这个还得具体分析
不知道你怎么测试的
我测试的结果,将AAAA从aaa移动到CCC,所有链接到AAAA的链接都坏了
这是最基本的重组
测试100%不会修改移动的标题链接
还真是…
我刚知道这还有个 “直接迁移小标题” 的功能
发现 Ob 这个 “重组功能” 有几个入口
- 命令行 - 笔记重组:将当前笔记合并到其他笔记中
- 命令行 - 笔记重组:移动当前章节
- 选中一些文本后右键 - 将所选内客移动到其他笔记中
- 在小标题上右键 - 移动当前章节
我之前测试的是第一个 “将当前笔记合并到其他笔记中” 这在简单情况下正常
而之后的三个 “移动当前章节” 等等, 感觉都是同一份逻辑: “把指定一小段文字, 移动到别处”
这个我刚测试确实不会维护链接, 跟楼主现象一样
这个确实是问题 Note Composer: links to blocks and headers should be updated when extracting - Bug reports
底下有人写了个 Better Note Composer RyotaUshio/obsidian-better-note-composer 我试试的
– Better Note Composer 看着还不错,
就俩命令 Better Note Composer: Extract heading
/ Better Note Composer: Extract selection
实测简单场景下, 挪走某章节/某选中文本范围时, 会自动更新其中链接
特别常用的话, 可以考虑拿 Commander 把命令填到编辑器右键菜单里
是的,我也是依靠这个插件解决的,但这应该是obsidian核心插件要解决的问题才对,所以说ob对链接并不是很上心,ob都出来多少年了,还得靠插件来完善一个最基础的链接的稳定性,,,