光子莲台

操作参考这篇回帖。觉得有必要改进可以去支持 Issue 14444 相邻容器块合并首层容器

支持，深度图谱的完整引用链路可以弥补思源所缺少的层级引用继承功能，只引用距离最近的块也能将关联传递得更远了。

那试试用集成编辑环境插件直接删掉主题所在文件夹再重下吧

不能正确更新的话可以试试清除浏览器缓存后重开

提供一些小方向吧。另外个人也不建议死磕白板，集市那么多成品半成品还不够好用说明这玩意对个人开发者还是过于困难了不集中力量很难做好。

1 指定行列数快速创建超级块表格

超级块作为“大区块”可以将块元素二维排列构造出块级表格形态容器，作为大号表格实用性远胜原生 Markdown 表格，弥补其各种不足，比如这里就有人用超级块搭建了复杂表格结构。所以希望能快速创建指定行数和列数的超级块，这样就不需要每次都手动合并调宽度了。大概算这篇帖子的升级版。

2 相邻容器块合并首层容器

• 用途

主要用来将几个断开的列表连成一个列表块。

• 功能

选中若干相邻的列表块，在右键菜单中提供《合并首层容器》功能。相邻引述块、相邻超级块同理，即若被选中块 a,b,c 首层容器类型一致，则点击合并操作仅保留首个选中块 a 的外层容器，其余选中块 b,c 的子层移到 a 的原有子层下方；如果容器类型为有序列表则更新序号。可以参考《合并为超级块》的选项位置。

• 分析

多个断开的列表块不能完美地快速合并，现有方法的问题：

1: 选中后先转换为段落，再全部选中转换为列表

这会导致指向列表项的引用失效，而且每次转换要重新选中，操作步骤多。

2: 选中后拖动列表项图标实现合并

这样不能一次合并多个相邻列表块，列表块超过 2 个时只能逐个合并。解决了这点的话也不失为一种方案，但其他容器块还是没法合并同类。

3: 选中后拖到目标列表子层，再反缩进

这个方法同时结合了法 1 操作多和法 2 不能处理多列表块的缺点。

相关帖子：思源列表反馈 | 有点奇怪的列表项逻辑

3 文档宽度超过屏幕宽度

这个功能是给移动端准备的，文档宽度相对屏幕宽度超过 100% 时向右滑动浏览。想要这个是因为手机屏幕大小有限，列表大纲的用法会带来很多缩进，严重削减竖屏可用空间。使用聚焦能稍加缓解，但一方面不停地聚焦返回操作繁琐，另一方面就算聚焦也要保留一定上下文，不可能永远聚焦在末级列表，那只要有列表缩进就仍会使横向可用区域大幅度衰减。

允许文档宽度超过屏幕宽度，像长公式块那样横滑查看就能解决手机宽度不足的问题，当然最好能把默认横滑打开菜单的交互也顺便禁掉。

一般刷新下界面就好了

我是激进派，我支持直接去掉侧滑交互，只用顶部图标打开菜单。

建议参考菜佬 @ACai ，Obsidian 笔记迁出问题挺多的。

Ob 转思源问题汇总

• 思源要能转换 obsidian 的 md 文档
  • 非标准加粗语法
  • [[^]] 块级引用语法
  • 元属性语法
• 怎样让思源兼容 ob 的 md 语法
  • HTML 样式问题
  • ![[]] 引用语法问题
• Obsidian 迁移到思源的踩坑之旅
  • 附件链接语法问题
  • 创建时间问题
  • 块 ID
• 一些看似容易迁移的格式（比如非标准 Markdown）实际上是无法迁移的，除非它的解析器是开源的。

你说的场景关闭笔记本就够用了。然后敏感文档不放在笔记本第一层，更敏感的就配置忽略搜索降低存在感。

上层不是任务列表的主任务：

.protyle-wysiwyg :not([data-subtype="t"])>[data-type="NodeList"][data-subtype="t"]>[data-type="NodeListItem"][data-subtype="t"]>[data-type="NodeParagraph"],
.protyle-wysiwyg [data-node-index][data-type="NodeList"][data-subtype="t"]>[data-type="NodeListItem"][data-subtype="t"]>[data-type="NodeParagraph"] {
    background-color: var(--b3-theme-surface) !important;
}
​

如果有嵌套列表会在 SQL 查询中出现容器块重复。解决方法有两个，一是把任务列表项作为 parent_id 只查叶子块，二是用比如 Query View 插件去重，QV 查询参考代码：

//!js
const query = async () => {

    const SQL = `
select * from blocks where
type = 'i' and subtype='t'
and markdown like '%[ ]%' 
and root_id='20250421154321-dyt29ku'
;
    `;
    let blocks = await Query.sql(SQL);
    blocks=await Query.pruneBlocks(blocks,'root',true);

    return blocks.pick('id');
}

return query();
​

在思源里我的建议是舍弃标签改用块引，反链过滤面板插件就和文中的功能基本一致

思源代码块好像没有对```语法做特殊处理，理论上 Markdown 代码块内的无缩进连续反引号个数不能与代码块界定反引号数量相同。

能打开若干网页快速切换，能启用垂直页签，能保存登录信息，这不和真浏览器一样吗

参考这篇回帖

我的意思就是先把要粘贴的内容贴到别的地方(个人用的 Notepad-- )，再重新复制粘贴到思源

试试不用 VS Code 中转粘贴，用别的记事本比如 Notepad-- 作为中转

从自身体会来说，思源列表的优势很简单就是它能放列表以外的东西。大纲笔记我只用过幕布这种极简化产品，就这么简单的使用我都感觉在反复面临那个圆点图标的拷打，不断提醒我“这一项和上一项是割裂的”。层级大纲毕竟只有上下层纵向关联和同层横向关联两种节点关联，要只用两种结构分清空间并列关系、演绎递进关系、论点-论证关系、归纳展开关系等种种逻辑关联还是比较困难，需要引入自然语言描述，于是「对节点关系的描述」本身也要建立节点，进一步增强割裂感。归根结底，大纲本质上还是适用于短文本内容组织的辅助工具，有的语义连贯的长内容本身就不应该镶在列表项里。

这篇教程的一些说法可能更有启发性，即：思源笔记的大纲具备真正的写作能力；思源笔记的大纲具备更好的制卡能力。纯列表大纲在“面对大段文本的描述时，很难以自然的姿态去对其进行语言上的衔接”，而思源可以非常自然地用列表节点作为概况项，下方则全部用常规段落块自然分段。比如我这篇回帖就是在一个链接列表项的子层写的，正文也有类似的示例图；至于列表大纲在进行面向输出的写作上的劣势，借用某佬在群里的发言：

链滴里偶尔看见有人用大纲来表达的，真的很难理解他在说什么。

感觉直接用书签 + 插件就行，支持书签分组、拖曳添加笔记等等，核心就是将多个文档保存在一起。

以目前集市白板插件挂件的割据格局，官方白板有可能永远不会实现了而会一直将重心放在其他功能的打磨上。非官方功能的主要问题还是开发资源分散，插件作者各自为战很难将成果联结。比如叶归插件的白板自身也是块，还能嵌入笔记内容块并同步编辑，在组织呈现上很有潜力；Whiteboard 挂件虽然只能将其他笔记拖进白板作为伪嵌入块，但其他元素更丰富，在自由输入上继承了 Excalidraw。想同时利用这些优点就很困难，白板套白板还是有点难绷，最后只能根据需求做取舍。官方白板的意义更多在于提供一个统一平台框架。

可以用 Savor 主题的子弹线样式(个人调整了非列表块顶层时的显示问题、非 Savor 主题激活节点显示)。

css 代码：

.en_item_bullet_line:not(.protyle-wysiwyg--select)::after {
    content: '';
    display: block;
    box-sizing: border-box;
    border-left: 2px solid var(--b3-theme-primary);
    border-bottom: 2px solid var(--b3-theme-primary);
    border-bottom-left-radius: 8px;
    position: absolute;
    left: -18px;
}

[data-subtype="u"] .en_item_bullet_line:not(.protyle-wysiwyg--select)::after {
    width: 32px;
    height: calc(var(--en-bullet-line-height) - 1px);
    top: calc(var(--en-bullet-line-height) * -1 + 20px);
}

[data-subtype="o"] .en_item_bullet_line:not(.protyle-wysiwyg--select)::after {
    width: 24px;
    height: calc(var(--en-bullet-line-height) - 8px);
    top: calc(var(--en-bullet-line-height) * -1 + 25px);
}

[data-subtype="t"] .en_item_bullet_line:not(.protyle-wysiwyg--select)::after {
    width: 30px;
    height: calc(var(--en-bullet-line-height) - 4px);
    top: calc(var(--en-bullet-line-height) * -1 + 21px);
}

/* 激活状态样式 */
[data-subtype="u"] .en_item_bullet_actived>.protyle-action,
[data-subtype="u"] .en_item_bullet_actived>.protyle-action::before,
[data-subtype="u"] .en_item_bullet_actived>.protyle-action::after {
    color: var(--b3-theme-primary) !important;
}

[data-subtype="o"] .en_item_bullet_actived>.protyle-action::after {
    background-color: var(--b3-theme-primary);
}

[data-subtype="t"] .en_item_bullet_actived>.protyle-action--task,
[data-subtype="t"] .en_item_bullet_actived>.protyle-action--task::before,
[data-subtype="t"] .en_item_bullet_actived>.protyle-action--task::after {
    color: var(--b3-theme-primary) !important;
}
​

js 代码：

allListItemNode = []
document.addEventListener('selectionchange', () => {
    const selection = window.getSelection()
    if (!selection.rangeCount) {
        return
    }
    const range = selection?.getRangeAt(0)
    const startNode = range?.startContainer
    let currentNode = startNode
    allListItemNode.forEach((node) => {
        node.classList.remove('en_item_bullet_actived')
        node.classList.remove('en_item_bullet_line')
    })
    allListItemNode = []
    while (currentNode) {
        if (currentNode?.dataset?.type === 'NodeListItem') {
            allListItemNode.push(currentNode)
        }
        currentNode = currentNode.parentElement
    }
    for (let i = 0; i < allListItemNode.length - 1; i++) {
        const currentNode = allListItemNode[i]
        const currentRect = currentNode.getBoundingClientRect()

        const nextNode = allListItemNode[i + 1]
        const nextRect = nextNode.getBoundingClientRect()
        const height = currentRect.top - nextRect.top

        currentNode.style.setProperty('--en-bullet-line-height', `${height}px`)
        currentNode.classList.add('en_item_bullet_line')
    }
    allListItemNode.forEach((node) => {
        node.classList.add('en_item_bullet_actived')
    })
})

​

1. 叶归插件
2. 反链过滤面板插件
3. 番茄工具箱

使用反链过滤面板插件能实现一层反链传递：在 A 中引用 C，然后设置筛选面板的 定义块范围=引用其他文档的定义块，就能使 C 的反链出现在 A 的反链面板中。B 同理。

Daily Note 本身是用来打破“必须在现有结构里填充新内容”的输入方法，将“考察现有笔记体系 → 定位合适位置 → 写入新内容”调整为“写入新内容 → 关联现有信息”，将输入以外的处理置后从而解放输入环节。思源手机端过于沉重了在轻量化输入方面其实不太合格，启动太费劲，最好还是搭配个能多端同步的快速记录工具比如语雀幕布 flomo 等。

解放输入大概率会导致笔记体量增加，当体量膨胀到一定程度时可能使得定位特定内容变困难。在记忆范围内的还能用搜索直达，而当记忆模糊导致搜索成为非完备信息提取时，就有必要通过关联信息属性增加与笔记关联的信息维度，从而增加找到符合指定规则的笔记集合的维度。添加双链、标签、数据库都是增加笔记的信息标签，从而只需要记住这些信息标签，有一个信息标签就能汇总所有相关笔记。这大概对应文中的初级整理，增强笔记可检索性。

当信息标签也膨胀到一定程度时同样可能会使定位笔记变困难，此时就要将重要的信息标签组织起来建立导航入口，在宏观视角上显式罗列笔记内容结构。添加索引笔记 | MOC | 结构笔记都是搭建导航结构，这大概对应文中的中级整理，提升笔记检索效率。

当与特定信息标签关联的笔记膨胀到一定程度时可能使这方面的认知产生质变，原本的碎片笔记就不是孤立碎片而是成为某个更大的主题的素材了，此时可以考虑进行输入 → 整理 → 提取 → 表达中的最后一环，基于碎片化的小笔记发展更完整全面的大笔记，原始的笔记素材沉淀为背景区或不再保留。这大概对应文中的高级整理，用写作实践使用笔记，用使用实践整理笔记。

管理活动是要通过有效组织去实现目标的，如果进行管理的结果只是发展出一套管理系统在内部去折腾那当然毫无意义。知识管理容易使人陷进去就是因为它就是这样一种“自指性”知识，或者说知识管理的知识的「用法」就是「管理」，学习知识管理方法很容易将组织整理作为终点，这么做表明从一开始就没想清楚知识管理的需求。直到不管理就不能用了才有做管理的必要。

笔记不等于知识管理，也从来不是仅仅用于屯放资料的；它可以是打开外部资料的传送门，可以是规划任务的根据地，可以是与过去的内生灵感型信息的对话窗。整理笔记没用吗？如果我想提升写作水平，而笔记里是我个人萌生的想法，那么整理笔记等价于梳理思维，可见无意义的并不是整理笔记，而是漫无目的地整理，脱离需求地整理。

有困难的从来都是明确现实目标规划。给需求以工具，而不是给工具以需求。

目前可以用面包屑从上层块跳转

添加标签、添加传递型引用、添加到数据库，都是将笔记与一个信息节点相关联。建立关联有几种作用，其一是为将来提取笔记提供检索的钩子，其二是用信息的关联表征其结构，其三是丰富知识上下文。任何建立关联的技术都面对着这些用途各自的困境。

检索困境：信息之沙，非我所取

笔记中少部分是用来即时理清思路以写代用的，大部分是用来面向将来的检索的，靠现在的努力让未来的自己能提取到想要的信息。然而记忆会衰减，现在熟悉的笔记未来迟早变得陌生起来。如果能记住一切关键点，那么只要靠搜索就能直达任何想要提取的信息；然而这并不可能，只要笔记内容充分多，未来的我就注定会忘掉绝大多数笔记。我记不住想找的笔记“是什么”，只能猜测其“是怎样”，通过过滤不想要的笔记增加找到想要笔记的概率。查笔记注定会遇到无用信息远多于有用信息、噪声包围信号的困境。笔记越多，拥有共同或相似关联条件的也越多，只能在记录整理时通过建立信息关联为其赋予尽可能多的差异性。

反映在反链上，笔记越多，块引一致内容不同的笔记也越多，筛选难度也越大。

关联困境：语义之林，非我所用

所有通过元信息建立关联的技术都有一个共同问题，那就是只能表明笔记间有关联，而不打开笔记就无法得知具体是什么关联。A 笔记引用 B 笔记，B 是 A 的上层？来源？引证？反例？历史版本？推论应用？......如果建立引用时就不考虑反链筛选，不同语义的引用全部混杂，那就必然导致反链可读性很差。

被引用不代表是我想要的相关和归属关系。

链接就应该支持标签，形成（A 怎么 B）而不是仅仅（A → B）的关系。

We should not only place a link but also strive to describe the type of the link relationship.

现代双链出自大纲笔记，所以用块引独占节点定义出了传递型引用。其实在锚文本上附加前缀才是最能表达不同的引用语义的，还有利于反链筛选，不会在多个块引共存时互相干扰。如果没有其他关联语义，只表示“属于”关系，那么我很喜欢用动态锚文本表示传递型引用的主意。

上下文困境：知识之海，非我可探

卡片笔记法等笔记术隐含的理念就是知识是可以原子化的，信息是可以封装成面向其他笔记的接口、通过引用来丰富上下文的。然而知识是不可胜数的，知识的关联更是比星罗棋布还浩如烟海，对于个体而言更是永远不可穷尽。一切笔记只能在特定知识范围内建立局域有效的认知理解，而未来的我大概率会否定现在的我的认知，使信息提取更加困难。信息如同熵一样永远只增不减，想维护结构就要源源不断地投入精力，在旧笔记上建立新关联。反链在展现内容上下文的能力上是超群绝伦的特性，然而搭建出笔记的网络不代表自身能理解这片网络，更不代表未来的自己同样充分理解这片网络，于是整部笔记成了深度无限的上下文之海。上下文太多导致组织不连贯的典型负面案例可能就是《卡片笔记写作法》这本臭名昭著的“教程”，如 BV13bySYVE2U 的评论所说：“他理解的方法论在框架上的缺陷和限制用了一本书的篇幅以行为艺术式的完美展示了给大家看”。

我知道的近期各版本出过的问题：

• 3.1.12：数据仓库自动清理 bug
• 3.1.13：反链异常高亮
• 3.1.14：Firefox 伺服 bug(关联、关联)
• 3.1.16：Markdown 导出为空，PDF 导出异常
• 3.1.18：Shift+Enter 软换行失效
• 3.1.19：行内代码显示异常

遇到了同样问题，默认主题无插件也存在行内代码导致的光标异常、文字消失，后者可以 F5 刷新恢复显示。

思源要在双链上走出自己的路了