光子莲台

Markdown 可以用手机导出

每行还是用 & 对齐，这个就是用来划分列的，奇数列右对齐偶数列左对齐

应该用 aligned

不是因为有双链所以无压，而是因为记录时可以随便放所以无压，因为少整理不整理所以无压，因为要用的时候能找到内容能快速从原处排版到正文所以无压。正链反链和细粒度都在鼓励将注意力聚焦于当下、聚焦于局部，因为注意力的容量小了所以才无压。记录时不求整理，整理时不求圆满，要用时能够找到，这样就够了其他的都是浮云。当然双链本身确实被神话过多了，说到底「正链用锚文本代表内容本体，反链提供引用的汇总」，链接本身不存在语义逻辑，不能指望双链搭建的关联网络成为真正的知识网络，想让这个偏底层性的语法实现各种高级功能自然就需要手动设计复杂的使用方法了，这显然就会与无压狠狠地冲突。

您的观点非常合理但是和这篇帖子说的并不是一件事。我采用了 MOC 面向主题地管理笔记链接的方法，内容结构并不体现在文档树上，当前已打开的页签组只有逻辑关联没有位置关联，所以与文档树没有关系。文档树的页面呈现当然更直观，而正是因为现有方案里已打开页签只能在横向空间上排布个个离得老远，所以才希望有一个类似于文档树的树状页签栏密集放置页签。

我感觉正是有了双链才导致内容更破碎了，才会存在更多文档同时打开的情形。双链不是标签不能超脱文档的载体，不同内容并不一定同时存在于同一个反链面板里，更不可能全部位于同一文档里。从双链哲学的视角看，已打开页签相当于在编辑器内构建了一个短生命周期的临时正链集合，正是因为存活时间灵活不定所以不能用真正的具有中长期寿命的双链取代其作用。我个人其实倾向于书签 + 插件的动态书签组设计，将《当前打开的页签》作为一个动态变化的书签组摆到侧栏。

Savor 的垂直页签我试下来有些问题，比如关不掉侧栏面板，面包屑和文档工具栏消失；而且既然专开了一片区域放置页签就不需要分屏时也分出页签栏了，用分隔线区分分组就可以了

多行显示页签的问题就是会占据更多的纵向空间，而且每个页签宽度不同反而没有垂直页签看着规整。其实增加页签 Dock 还有一个优点就是对移动端更友好，目前我都不知道怎么在手机上切换打开的文档()

把两个 flalign 替换成 aligned

稍微整理了一下。

二级文档树的功能

两个面板分别罗列本级文档的相邻文档和本级文档上方父文档的相邻文档。

• 不需要增加三级、四级文档树，二级文档树的《本层 + 上层》足够产生质变
• 与父子文档的理念并不冲突
  • 原本文档树的展开变成：将本文档(和同层文档)放到一级面板，其子层文档展开放到二级面板
  • 原本的折叠变成：将本文档(和同层文档)放到二级面板，其父层文档(和父层的同层文档)放到一级面板
  • 进一步优化操作的话可以 Ctrl+左键 展开文档子层，Ctrl+右键 展开文档父层

二级文档树的作用

检索文档时增加信息密度

• 两级文档树可以增加文档上层的上下文信息展示。因为屏幕纵向高度有限，若某一层级文档较多，则单列文档树难以同时查看本文档相邻文档、上层文档相邻文档，而后者具有更宏观的分类视角
• 文档级别的检索浏览是一个宏观操作，需要有足够大的全局视野在不同笔记分区上快速切换
  • 与文档树 + 大纲的差异：
    文档树 + 大纲 + 编辑器可以实现 文档层次上下文+大纲层次上下文+内容上下文，看上去是并列的不过后两者的作用域更加精细。而二级文档树关注的是更上层的 同层文档上下文+父层结构上下文，具有更高层次的观察视野，并不需要与大纲同时长期显示。
• 同理，如果需要在某个层级上切换文档时观察其子层文档，不使用二级文档树就需要不断地展开折叠
• 这一点可以采用文档层级导航插件稍作弥补，但显示效率仍然不如二级文档树；且还是不能解决文档过多时难以用文档树检索的问题
• 采用文档链接组织 MOC 可以代替文档树的分类功能，但同样存在问题
  • MOC 的文档天然可分屏虽然有利于多视角检索，但不同页签缺乏二级文档树的联动性，还是要手动展开折叠
  • 此外，文档数量较大时 MOC 目录也会变得极其巨大，而拆分 MOC 目录页同样会损失全局预览能力

移动文档时简化操作

• 高效的文档切换使二级文档树能大幅提升文档移动体验，参考 MT 文件管理器的双窗口操作
• 右键移动时同样面临只能查看单列文档树的问题，除非同时显示同层文档和子层文档；此外批量移动时手感同样较差
• MOC 文档的链接移动起来更方便，但是：
  • 完全不移动文档本体，意味着文档数量不断增加会出现拖累性能的风险，而且不能采用关闭笔记本的方式缓解。而个人笔记这种超长使用周期的工具，即便是潜在的性能问题也会严重挫伤使用动力

只要想移动文档，二级文档树几乎就是最优解决方案。

赞同帖主，二级文档树对于依靠文档树进行笔记管理的用法确实是点睛之笔。个人理解，二级文档树的核心特质其实是增加了文档层级的“上下文信息”，能够同时展示子层文档和上层文档的相邻文档，在文档树中翻阅文档时可以同时查看目录和目录的目录。这个功能和大纲面板相似的地方在于，有了大纲面板既能在编辑器看到当前内容的上下文，又能在大纲中看到当前内容所属大纲层级的上下文。但是大纲层级与正文是非同质的所以做二级面板没有意义，而文档和子文档是同质可嵌套的，增加二级面板有利于快速切换观察视野，所以二级文档树确实能为文档检阅体验带来本质跃升。

遗憾的是思源本身没有鼓励使用者用文档树做笔记管理，很多人倾向于用链接 MOC 管理笔记文档，可能不太会把二级文档树功能给做出来了，毕竟采用「正向引用」组织目录结构确实可以解决很多问题。题外话，与其他软件相比感觉思源笔记其实也只是比毛坯房好一点而已，可能也就是不那么毛坯的毛坯房，怎么用都得各种将就。

思源图标难绷很正常，毕竟这玩意当初大概花了几分钟做的（）

使用快捷键 Ctrl+M 进入行内公式，写完 Esc 回到正文

其实不是 bug 而是列表块的特性，感觉每个月都有人问这个（）

列表的实现方式是列表块嵌套列表项嵌套其他块。无序/有序/任务列表块作为容器块，其本身不包含内容而是将列表项作为内容，即一个列表里有若干列表项；列表项作为容器块，其本身不包含内容而是将其他块作为内容，即一条列表项里可以有若干个块。列表项的第一个内层块是这条列表项圆点图标后面的内容，其余内层块则位于其下方作为子层内容。不同列表类型的列表项分属于不同列表块。所以：

• 不能直接在无序列表里把一条列表项转成任务列表；
• 列表项里可以嵌套任务列表块，灵活使用 Backspace 清除不需要的块层级。

第 1 个图的显示问题，可以尝试 F5 刷新。

反链还是有潜在用途的，个人用到的有：

• 传递型引用，正链用于在日记记录时指定内容归属，反链用于在主题中汇总其他位置下的所属内容；
• 链接 MOC，正链用于以链接形式组织分类，反链用于跳转回上层分类；
• 关联型引用，正链用于以锚文本调用内容本体，反链用于汇总与内容本体有关的其他主题；
• 内容重述，正链用于指向内容原始形式的本体，反链用于查看本体内容的其他表述形态。

问题在于，双链是一个底层性的语法而非业务性的功能，其用途并非不言自明的。正链反链只能揭示块与块的引用关系，但这种引用关系具体在表达什么逻辑关联需要靠上下文等来解读。但是思源原生的正链缺少合适的分类方法，反链缺少合适的筛选方法，导致想把双链用成多种功能时不好进行区分。可行的区分方法：

1. 在引用形式上区分，比如一个块里只有引用表示它是传递型双链，比如星号作为锚文本表示它是用于块重述的双链。这种方法的问题是反链面板不好筛选，需要使用 SQL 配合插件手动筛选，否则反链混在一起只能肉眼观察。
2. 结合使用标签、单向块链接、动静态锚文本、嵌入块等多种语法，但各有各的问题：

• 单向块链接不能被转移引用，不利于文档重构；
• 标签能嵌套，但不能转换为引用，且标签本质上没有正链本体；
• 静态锚文本不好编辑；
• 嵌入块只适合显示已有内容，不适合进行修改，且一旦失效难以追溯。

个人希望的一种双链改进方案：为引用添加自定义类型属性，建立引用时可以自定义引用的类型，在反链中可以选择仅列出指定类型的引用。

这是从功能区分的角度进行改进。至于在某种特定功能的双链里靠算法而非人工阅读来判定相关性，可能还是 AI 能做得更好。

可以给常用块添加命名试试

正统的 Markdown 支持 HTML 语法，所以 HTML 注释会不被显示，可以在注释中写东西还不影响 Markdown 文档的渲染效果；而思源内不支持直接使用 HTML 语法，放在注释中的内容会正常显示出来。理想情况是在写作时把一些不需要显示在发布中的内容放在 HTML 注释语法里，然后导出 Markdown 文档在预览时不会将其显示出来。现在看来这个操作其实局限性不小，最好还是具体情况具体处理。

为什么最后会有我

这不就把您吸引过来了吗()

能贴一下日记片段截图吗？

我算是个笔记初学者，文中列举的工作流暂时符合自身使用了所以写点东西作为总结，结构上还是非常朴素的，请大佬斧正

重述型引用其实就是用星号 * 作为引用锚文本，比较显眼。我在日记中也使用传递型双链对内容进行分类，比如文中的例子：

# 日记
- [[练字]]
    - 倾斜偏旁可以压缩其横向空间
    - 字与字既要充分紧密，又要毫无接触

上面这一段是某一天日记的一条；等后来想整理相关内容，进入 练字 的主题文档打开反链面板，它就会出现在其中；我找到与第一条有关的笔记：

# 练字
- 空间合理
  - 空间挤占→避让
    - 左右结构左右压缩
  - 空间空余→穿插

把日记中的条目复制粘贴进去：

# 练字
- 空间合理
  - 空间挤占→避让
    - 左右结构左右压缩
    - 倾斜偏旁可以压缩其横向空间
  - 空间空余→穿插

然后在主题文档中对这一条的块标右键复制为块引用，在日记文档中的条目末尾粘贴引用并对块引用右键 转换为 *。等都整理完了再把日记中的 [[练字]] 右键转换为文本，最后日记内容变成：

# 日记
- 练字
    - 倾斜偏旁可以压缩其横向空间 *
    - 字与字既要充分紧密，又要毫无接触 *

这样既把内容汇总到主题中了，又在日记中保留了原始内容；在主题文档中进入块反链，根据带 * 者查看这段内容进行过怎样的改写；在日记文档中进入块的 * 引用里查看这段内容的本体表述。个人用法仅供参考。

关系图主要用于展示引用关系而不是文档内的层级结构(不然就和大纲重复了)，而图中连不上是因为把标题嵌套在列表项里了。

标题与文档可以互相转换是写进帮助文档的，而列表项可以单向转换为文档甚至没写进帮助。

Shift+Tab 将目标列表项反向缩进一层，然后在段首 Backspace 将列表项转段落

跟进分享~

折叠列表项环绕虚线

参考此链接：

.protyle-wysiwyg [data-node-id].li[fold="1"]>.protyle-action:after{
    border: 1px dashed var(--b3-font-color1);
    transform: scale(1.35);
}

移除块滚动条

.protyle-scroll {
    display: none;
}

块引用锚文本附加 ｢｣ 符号

彩色｢｣符号并区分动静态锚文本

:root {
    --b3-protyle-inline-blockref-color: var(--b3-theme-accent);
}
.protyle-wysiwyg [data-node-id] span[data-type~=block-ref]::before {
    content: "｢";
    display: inline-block;
    font-size: 100%;
    color:rgb(137,87,229);
}
.protyle-wysiwyg [data-node-id] span[data-type~=block-ref]::after {
    content: "｣";
    display: inline-block;
    font-size: 100%;
    color:rgb(137,87,229);
}
.protyle-wysiwyg [data-node-id] span[data-type~=block-ref][data-subtype="s"]::before {
    content: "｢";
    display: inline-block;
    font-size: 100%;
    color:rgb(137,87,229);
    transform: scale(1, -1);
}
.protyle-wysiwyg [data-node-id] span[data-type~=block-ref][data-subtype="s"]::after {
    content: "｣";
    display: inline-block;
    font-size: 100%;
    color:rgb(137,87,229);
    transform: scale(1, -1);
}
span[data-type~=block-ref] {
    font-weight: unset !important;
}

导出 Word 时公式渲染失败可能与多行公式有关：公式块如果含有以 \\ 换行的多行公式，在思源里可以正常显示，但是导出 Word 时必须使用正统 LaTeX 语法，比如将多行公式置于 aligned 环境里

提及是尝试寻找当前内容的潜在反链，虚拟引用是尝试从当前内容建立潜在正链。

个人使用文档层级导航插件查看当前文档引用了哪些内容。

块右上角有引用计数，可以看到一个块被引用了几回，处理的时候注意一下就好。

至于找文档的话我是把文档引用放进 MOC 或者数据库的，重构文档树太费劲了

图片滑块还有个 bug，就是在其嵌入块上直接拖动滑块会导致图片变成 HTML 块

聚焦到列表项可以展示其子层列表，光标在子层列表时可以 Ctrl+Shift+N 跳到上层列表下一项。标题同理

直接 Ctrl+↑ 响应比较快

将就一点的话自定义块样式插件可以将列表转为导图