关于思源笔记编辑器的一些想法
列表块存在的必要性
列表块包含列表项块,但是除了列表项块,别的类型它都不能包含,所以其意义仅仅在于将几个列表项块看作是一个整体。在实际应用中的意义不大。
- 那么列表块的应用场景有哪些:
-
在一个文档中以大纲的形式使用列表
- 如果需要引用整个大纲,那直接引用文档块就可以
- 如果需要引用某一个“大纲”节点,则引用对应的列表项块就可以
-
在文档式笔记中作为某些事项的元素列出
- 例如:
内容块的类型有:
- 段落
- 列表
- 例如:
-
目前唯一感觉有必要存在列表块的场景
- 在文档式笔记中,出现一段“大纲”式笔记,且和上一段内容无关时
- 例如:
以上说的是一个问题。以下说的是另一个问题
- xxxx
- xxxx
- xxxx
-
但是,如果在文档模式中的大纲的列表块可以归属于上一段内容的话,那么所有列表块都可以以归属上级内容引用,这也符合列表的传统用法:给出列表标题,然后书写列表。当然这么做,就涉及到列表归属的问题。在目前标题块和段落块还是叶子块的前提下,似乎不可能实现。目前可以通过上文的例子暂用(["列表用法示例"])。就是先建一个列表项,然后列表写在列表项下一级,引用的时候引用第一个列表项(类似大纲用法)。
所以,我认为列表块存在不是很有必要,且增加许多问题。
列表块的问题
面包屑导航的层级问题。对于一个列表块,在面包屑导航上该显示什么内容,如何同列表项内容区分,又或者是不显示列表块。
对于引述块和超级块也有类似的问题,在这种类型的块中,其本身没有内容,但是却构成了格式上的层级关系。
列表大纲和标题块混用的逻辑混乱
一般来说,我们只会使用一种形式来做文章的层级关系梳理,这样就不会造成这种歧义。但是不排除有人在大纲中使用标题,这样的文档层级关系到底是怎么样的?
- 例如:纯大纲式内容
- 层级 1 鼠标 1
- 层级 2
- 层级 3
- 层级 2
- 层级 1 鼠标 1
- 例如:大纲混合标题
- 层级 1 鼠标 2
-
标题 1 鼠标 3
- 层级 3
-
标题 2 鼠标 4
-
- 层级 1 鼠标 2
例如:标题混合大纲
- 层级 1 鼠标 5
- 层级 2
-
标题 2 鼠标 6
-
标题 6 鼠标 7
-
- 层级 2
大家可以自行把鼠标放到对应位置,查看面包屑导航的情况(文档已上传)。可以看到,虽然单独的大纲或标题嵌入另一种格式内部时,都可以从外部层级导航到对应节点。但是,当标题和大纲来回嵌套时,处于大纲内部的标题和外部的标题之间仍然存在归属关系(对比鼠标 6,7),所以导致导航的层级一直在变。在鼠标 6 的位置,因为是个 2 级标题,所以在此处导航将原本隶属于“例如:标题混合大纲” 标题 4 的大纲“层级 1 鼠标 5”下属内容移到了 标题 1 的层级以下显示;而 鼠标 7 的位置,导航又因为 鼠标 7 是标题 6,而将大纲“层级 1 鼠标 5”下属内容放到了 “例如:标题混合大纲” 标题 4 下。
同时混用大纲和标题后的 文档大纲 (alt + 2)也是混乱的。
以上的例子不是为了故意制造混乱,只是为了说明,列表项的的容器属性在包含标题内容时候会出现问题。一种可能的方式是列表项的标题只有样式属性,不要有层级属性,但是这又会导致正文的标题解析问题。
设想的解决方案
将所有块类型的层级归属信息清除,所以层级关系以行首 tab 缩进来体现,可以参考 wolai。也可以是类似传统文档格式的形式,见下文‘关于新方案的注意点’。
解决方案示例-标题形式的文档
# 标题
标题内容1
标题内容1的下属内容
# 标题2 标题2 没有缩进,需要开发做好解析处理
标题2下属
- 和标题2下属同级的列表
- 下级列表
正文内容1
正文2
解决方案示例-大纲形式的文档
和目前差不多
解决方案示例-混合大纲和标题
# 标题1 层级1
内容
- 大纲1 层级1
- 标题2 层级2 鼠标1
鼠标1位置的面包屑导航关系为:文档 > 大纲1 > 标题2。此时的标题只有样式没有层级关系
新方案的引述块和超级块
两种块可以被引用,引用为其包含内容的表现的形式。但是在导航中,这两种块不作为一个层级。
超级块
此时的块都没有层级信息,所以处于超级块的内容块按照从左上角的顺序按本身的 tab 层级信息显示。超级块的直属块是同级的。
# 标题1
{
{{- list1
- list 2}}
{{- dafs
内容
> 引述 鼠标 1}}
}
鼠标1 的导航:文档 > 标题1 > dasf > 引述 鼠标1
引述块
和超级块类似,内容导航层级从引述块所处的位置开始计算,但不计算引述块本身。
可选方案
如果去除了超级块和引述块的导航显示,可能会导致有些人不清楚内容是不是在引述块和超级块内,可以选择显示引述块和超级块的块标,但不显示内容。
关于新方案的注意点
技术层面就不说了,我也不懂。
形式层面,如果全采用 tab 缩进确认层级的方式,可能涉及到文档写作时出现太多的缩进的问题。需要做进一步处理。
-
如果有
# header1 ## header2
解析为:
- header1 - header 2
-
但是如果出现
# header 1 text1 text1.1 ## header2 text2 text2.1 # nest header 这里继承层级关系 text3 ### header 3
那么解析为
- header1 - text1 -text 1.1 - header2 -text 2 - text2.1 - nest header - text 3 - header 3
如果能解析成这样应该就可以了,有点类似 toml 格式解析那样。现有的大纲面板可以取消,配合同级面包屑导航使用应该更好,面包屑导航可以参考 vscode 或 onecommander 的 navigation,但不要做那么大面积。
如果确实需要 # 这样的标题层级信息,自己也能注意不在大纲中使用 # 标题,那么可以搞一个选项 以 # 作为行首的,单独提取做导航。
关于新方案的总结
简单来说就是:
- 去除各个类型块的层级属性
- 将所有层级关系放到统一的形式下进行处理
- 下级块的层级关系继承上级块的关系(引述和超级块)
- 删除列表块,如果不删除,做和引述和超级块一样的处理也可以。
结合子文档的设想
既然目前已经实现了子文档,那么在实现整个思源笔记库成为一个整体就没有技术难度了。基于所有文档都在 一个库中,可以实现非常自由的层级转换,拖动,变更所属等操作。
对于文档的组织结构,设想如下:
具体例子:
在 ‘文档1’中有:
- text
- concept 【如果被标记成为目录】
- xxxxx 【上级节点为目录,下级内容自动成为文档的内容,但是位置和组织形式不变,类似目前的聚焦结果】
- text2
那么在目录上有,concept 显示
在所有文档或概念中有 文档1 和concept 两个入口。
最后几句
我并不在意原始格式是不是 md 格式或 json,如果能用数据库等其他格式能提高运行速度,那就用。只要数据文件是存储在本地,思源本身也是离线软件,即使将来不再继续运营,也可以保证最后的版本能够让你查看和导出自己的数据。当然想要完美兼容其他软件估计是不可能了,据个人了解目前没有哪个软件的格式可以完美和其他软件兼容。我觉得只要保证你写的笔记信息完整就好了。
关于外部查找。如果使用了类似数据库这样的非文本格式作为数据存储,可以提供 api 或者其他方式调用思源进行查找。配合 listary 或 quicker 自定义命令都可以比较方便的使用。
思源老用户了,希望思源越来越好。浅薄之见,希望能对开发者有启发。谢谢。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于