我认为离线功能要免费的最大最重要理由是本地内容的保全。必须保证，有朝一日哪怕思源倒了，本地的笔记数据也必须能由软件原样完整展现。本地有数据，但被会员制限制而无法展现，那就是没有数据，那就是丢内容了。

使用 Alt+【往往是在既有文本上建立链接对吧，这个时候应该默认此文本具有上下文，保守地以静态锚文本为默认是合适的。两害相权取其轻

静改动及其他转化都在右键菜单里，不用一个个删。

1. 从众不能把自身的优势从没了。既然文档块与内容块是统一的，是可以便捷地互相转化的，那这一点就应该作为特色而宣扬。相应地，设计逻辑上和实际操作上就不能背弃这个统一性。
2. 顺带夹个私货 ，目前文档块与内容块的统一是不完全的。
   1. 文档块标题只能是文本，无法打上链接，内容块向文档块转化中，如果该内容块的标题块上有链接，则会失掉。
   2. 我一直是将文档块标题视为一个标题块的，因为文档块转内容块后，它就是一个标题块下附具体内容。据此推导，在一个文档内，文档标题应是一个（相对）顶级标题，文档内当不允许设置“一级标题”。至于文档标题是定死为一级，还是浮动的相对最高级，我暂且没个主意。
3. 顺带夹第二私货 思源里有各种块及其嵌套，在检索时会有多次命中的情况，这要求展示检索结果是，要考虑排序权重。这是已经讨论充分的话题。我没异议，只是在畅想，如果技术上可能，可不可以不走“排序”的方案，而是走“分栏分类”的方案。
   1. 抛开移动端不论。
   2. 在使用大纲组织文本的情况下，引用其中一句话，出现的既有段落引用，也有列表引用。但是，据我体验，当检索词比较具体的时候，段落引用和列表引用才会一起出现；不太具体，也就是检索结果过多时，则不会。同一份语义内容散落在不同位置，总是不太好的。
   3. 反正电脑屏幕都是宽屏，何不利用起来？就像全局搜索由竖排改分栏一样，引用检索为什么不能也搞分栏？
   4. 从左到右：标题栏（包括文档，联动第二点），块嵌套栏（以列表为典例），基础段落块栏。
   5. 分类逻辑：
      1. 笔记，记写的是一份语义，这份语义落到思源编辑器里，首先，一定要落到一个段落块里，这是语义承载的基底，所以要有基础段落块栏
      2. 其次，语义内容可以形式化组织
         1. 以段落块为单位，简单的排排坐，谁大谁小，谁坐谁后面。对应标题等级。
         2. 以段落块为一份内容，用一个块装另一个块，如列表、超级块等等。对应块嵌套。
      3. 这个分类应该是完备的吧。
   6. 分栏分类的好处
      1. 顺手解决眼下的[[文档块问题。你只要看左栏就好了。
      2. 更好地利用宽屏，扩大检索结果呈现效率，逻辑与全局搜索由竖排改分栏一致。
      3. 方便识别引用对象类型。现在识别要引用的块的类，是靠的图标，图标当然没问题，就是有点累眼，你要有意识地去读图标才可。分栏分类后，就几乎不用再去读图标了。
      4. 直观展现语义内容的组织性、逻辑性。这份逻辑我上文已给出，当然咯，只是抛砖引玉而已。
      5. 对小白好。小白用户应该不懂得区分段落块和列表块的，分栏分类可以强制灌输软件知识，免得小白笔记引用得混乱乃至丢失引用。

😂 更新快，变动大，又没有事前告知与铺垫，既是优点也是缺点，思源特色，不得不尝

重建双链的话，注意区别段落块和列表块。双链，链接的是块 id，如果有一段话是组织在列表里的，那这段话既在一个段落块里，也在一个列表项块里，如果这段话是列表首项，那它还会以列表整块的形式出现。也就是说，同一段话，你可能链到 3 个 id。

链段落还是链列表，注意区分。

外观-代码片段，创建如下：

/*

• @file < 工作空间 >/data/widgets/custom.css
  */
  :root[data-theme-mode=light][data-light-theme="Dark+"],
  :root[data-theme-mode=dark][data-dark-theme="Dark+"] {
  /* 空行提示 | Blank line prompt */

}

试试看。我当时鼓捣了很多方法，并不确定是不是这个代码片段生的效。

我倒是认为这方面不认真才是妥当的，认真的会发现有“中文”但没有“中语”，而是“汉语”。“汉”一旦被带出来，“汉”与“中”的关系问题也要跟着被带出来了 😂 就无意识地下意识地用名称，就行了。

按我的理解，它是“潜在引用”、“可能引用”，要用“拟”字，“引用代拟”应该胜于“虚拟”。

段落嵌套就是没有符号标志的列表呗。

我的使用体验是，要大规模的使用结构化排布，那干脆直接用列表块。只有在涉及单个段落时，才有段落嵌套的需要——文章中的一个段落突然缩进并前缀了一个符号，太破坏排版了。

因此，我认为段落嵌套的需求可以窄化、具体化为：让超级块支持嵌套。

超级块的创建，本身就出自文本结构化需要，所以对超级块内部也作结构化，应该是合乎逻辑的。

超级块的边框我也想要很久了，目前的应对方案是用 dark+ 主题，这个主题给超级块打了颜色，然后打开 config.css，把超级块背景颜色那部分删掉，于是就获得了超级块的边框。

那有办法让链接只是失效，而不让“[1]”变成“[]{#_1.anchor}^[[1]]{.underline}^“之类的吗？

关于链接有两个小细节

一、思源里可以方便地把标题块拖进文档树，形成文档。但是，如果你标题处是有所引用的，在你把它单列成文档后，就会发现引用链接没了，因为文档标题处只能是纯文本。

二、把普通段落 a 快捷地转化为大纲列表，有两种办法，一是鼠标操作，通过块标菜单转换；二是键盘操作，“-”+“空格”。这二者不等价。方法一的逻辑是新生成一个列表块 id，然后把 a 装进去作列表子项。方法二是把 a 原本的 id 就地转成列表块 id，内容 a 改装进新生成的段落块 id。

这意味者，如果你在 B 处引用了段落 A，然后你把 A 处用键盘操作转成列表，再把列表取消，你就会发现 B 处引用成了空白。

附议。

把父文档的图标修改成文件夹样式，不就得到一个文件夹了

附议。立刻就清除也太严苛了。七天我还嫌少了，缓冲期一个月也不为过 。

似乎带“Click”的快捷键都没列，是考虑到因为要动鼠标，所以不算快捷键吗？我觉得还是应该算的吧

确实还有这种情况，没我想得那么简单。感谢你的补充。

怕误删就用现有的删除呗。

我修改一下措辞，免得被误认为是修改现有功能

不好找啊。我这有历史遗留因素，未引用资源里一大堆东西。

有一种导致引用丢失的情况，如果是，那就找到原因了；如果不是，有助于再多留一个心眼。

1. 被引用内容 A 原先是普通文本，在 B 处被引用了；
2. A 使用：“-+ 空格”快捷生成无序列表；
3. B 处引用仍在，且内容跟着多了个无序列表的符号”·“；
4. A 处删除“·”或者使用块菜单转换功能，把无序列表重新改成普通文本：
5. B 处引用消失。

原因在于第二步。列表套文本涉及两个 id，列表块 id 套文本 id。“-+ 空格”的操作逻辑是把普通文本 A 的文本 id 直接改型成列表 id，而普通文本 A 的文本 id 则重新生成。而 B 处引用的 id 还是旧的。所以当 A 处取消列表块后，B 处的 id 就成了空指。

与之不同是，第二步生成列表块的方式还有一种，就是通过块菜单里的转换来做，这时候它的操作逻辑是符合最直观的直觉的，即在原普通文本 id 外再重新生成一个新的列表 id 套上去。此时取消列表块，文字所在文本 id 仍旧是以前的，B 处引用也不会丢失。

加个 jpg 看看是不是图片

挂件与官方支持的差别，在我看来，只在于是否能把特定挂件的功能集成到右键菜单上，只要右键左键分别点两下就好，而不是现在先“/"，再找到挂件，再从挂件列表里选。怎么越说越感觉像 quicker 了…………

是的，之所以还这么提，是我目前暂未想到多一个标题又能有多大副作用呢？就内容而言，多出的一个标题不是嵌入原来正文里的，是空降到正文头上的，是凌空挂着的。就算把新成立之文档再拖回成文档内的块，也不会多费多大事，删除一行字而已。因此就我而言，没算到有什么副作用。当然，还是要多听别人的意见。

代为回复一下：“这样的话不是同一个块了哦”，确实不是，但是可以换个方向，不是新建一行正文，而是新建标题，即当我们把块 a 从文档 A 移出时，新得的文档 B 直接以块 a 为正文内容，同时提取块 a 的标题文本，以之自动创建为文档 B 的标题。

1. 所以，问题回到了最初，“只能转换为普通文本”的“只能”能不能变变。
   1. 如本贴正文最后一段所说，既然文档块与标题块互通，“导出”功能里也有标题作一级标题插入而后导出，那为什么文档标题不与文档正文打通？你看，你们自己写用户指南时，子标题大纲等级都是从二级开始的，跳过了一级，我猜测这不正是默认了一级由标题填补？
   2. 倘若不能的话，也就只有在做笔记时多多注意了。
2. 刚才疑似测出了一个新问题：我在“概述”那一行不是建的“内容块”的引用嘛，可我一开始是想建本文档“内容块属性”的引用的，结果如图：
   居然没有。是搜索规则上排除了本文档引用吗？

没问题啊，指南里写的是直接拖拽，我也是拖拽的，引用就是没了。

测试：

第一步，如下图，在“概述”标题上建一个引用

第二步：检查引用关系，无误

第三步，拖拽而后检查引用关系，丢失

不好意思 🙏 ，我没明白这是哪个功能，是块菜单里找吗？没找到啊，能再说得详细些吗？

就是针对你第二种情境，“把鼠标放到图片所在行，然后 Ctrl+、呼出块标菜单，点击菜单里的折叠”是有效的。

它的有效性可以佐证，有子项的父项也是以段落块为基底的，只是这个段落块的块标遭到并省，只能键盘打快捷键呼出。

针对第一种情况，列表的折叠都是折叠到第一项的，图片本身就在第一项，所以折叠无效。办法也是“把鼠标放到图片所在行，然后 Ctrl+、呼出块标菜单，点击菜单里的折叠”。

至于快捷键，为什么第一种情况下它作用于段落折叠，而第二种情况却又是列表折叠了，它到底是出自怎样的设计逻辑，我还不清楚。

如果要求的折叠不是缩略图的话，那么图片所在段落块是可以直接 ALt+Click 折叠的，折成只有图片最上方那么一窄行。

大佬，能借楼在这给 dark+ 提个建议吗（没 github 号），能不能让全屏后的背景图片沿用之前非全屏时的图，而非像现在这样全屏后改为默认背景图？或者说教教我怎么设置？谢谢 🙏 这点对于有随机背景图片功能的主题来说尤为有用。