相邻顶级列表按tab合并|按shift+tab拆分

[iamqiz]

在什么情况下你需要该特性？In what scenarios do you need this feature?

目前问题: 当前对一个 列表项按shift+tab反缩进时,如果成为1级项(顶级),那么该列表项会变成段落块, 如

但是这个操作很难逆向,首先项2变成了段落块, 从段落块变成列表块没有快捷键; 其次即使项2变成了列表,但是按下Tab却不能和原来的项1列表合并了

因此有了这个提议

描述可能的最优解决方案 Describe the optimal solution

建议: 如果两个列表所在块相邻, 那么按下tab时,先将两个列表合并为一个列表(同属一个块) 如下; 后续再按Tab,那就是目前的机制了

相应的shift+Tab反缩进时, 先拆分成两个不同块里的两个列表, 再按shift+tab才像目前这样变成段落块

描述候选的解决方案 Describe the candidate solution

No response

其他信息 Other information

No response

[88250]

通过这个操作来合并两个列表暂时不考虑了，建议用拖拽，谢谢。

[iamqiz]

@88250 为啥不考虑呢? 拖拽需要用鼠标,不如键盘方便

[88250]

对于分隔的两个列表的情况会改变操作预期。

[iamqiz]

能具体一点吗?

[88250]

通过 Shift+Tab 缩出到段落，这时候是不想 Tab 就合并列表；如果是两个列表的情况也是一样。

[iamqiz]

对段落进行tab ,不合并列表; 对顶级列表的第一个列表项,进行tab 默认是没反应的, 这可以改进为合并到前面的兄弟列表里; 像下面这样,对3进行tab,

[88250]

我的意思是这个改进不一定符合用于操作预期，所以建议还是用拖拽完成。

[iamqiz]

这是 "shift+tab 一个列表,变成段落" 的逆向操作, 我觉得符合操作预期 不然什么才叫符合预期?

[88250]

现阶段暂时不改变好一些。

[iamqiz]

其实 notion系笔记(notion/wolai/flowus)还有 logseq/obsidian , 它们是可以直接对段落进行tab 来使得段落能嵌套形成树状结构的

思源不打算这样做吗? 考虑到思源的段落不支持,那么列表应该支持啊, 但是不同的列表并不能方便地通过tab合并 键盘党表示,鼠标拖拽什么的, 太麻烦了,又不是左右结构,没必要拖拽 所以能不能支持一下?

[88250]

我觉得可能需要收集更多反馈才能决定是否支持，不然这个交互改动可能会影响一些用户的使用习惯。

欢迎在链滴上发起投票看看其他人的反馈。

[iamqiz]

在上面的那些笔记中,它们的基本块表现地像思源的列表项, 可以随意tab缩进形成嵌套结构, 优点是连 h1 ,h2 这样的标题 都可以省略了, D大觉得段落缩进形成嵌套结构怎么样?

[88250]

我觉得现在这样已经够用了 :joy:

[iamqiz]

那为啥其他笔记支持呢? 😂

[88250]

设计上不一样，其他产品已有的特性思源不一定能有。

[iamqiz]

@88250 我研究了一下,感觉是能兼容原来的思源数据和markdown的

原理就是将现有块增加一级,作为列表项,(我看了一下 logseq,它的每个块对应的markdown源码都是一个列表项. )

具体地: 导入markdown到思源时, 将每个1级元素增加一级,变成列表项, 比如下面这样

原markdown:

增加一级之后:

导出思源为markdown,则过程相反, 退一级

对于原先的思源数据, 按导入markdown的逻辑处理,将其增加一级,然后在sy文件中增加一个版本号属性,表明是新版,下次读取时不再进行转换.

处理之后的基本块统一都是 NodeListItem 列表项块, 文档可以看作是 NodeList列表

D大觉得咋样?

[88250]

我觉得还是不改动为好，不然这样的话会改变原有 Markdown 导入的结果。

[iamqiz]

导入之后,每个1级列表项前面的小点,隐藏掉, 用户看到的和原本一样, 结果并没有变,如下图

[iamqiz]

设计上不一样，其他产品已有的特性思源不一定能有。

段落嵌套是主流设计

[88250]

设计上不一样，其他产品已有的特性思源不一定能有。

段落嵌套是主流设计

技术上改动太大了，难以评估工作量和可行性。所以现阶段我们就不考虑了。如果有社区开发者愿意深入这部分技术细节，可以讨论看看。