Closed calmwaves111 closed 2 months ago
```timeline
[line-3, body-2]
+ 2023-04-22
+ 发现
+ 发现了一个新插件anyblock,https://github.com/LincZero/obsidian-any-block/
+ 2023-04-23
+ 使用
+ 很好用,解决了大问题,尤其是很多插件都是用代码块来渲染的,比如ad,比如[timeline](https://github.com/George-debug/obsidian-timeline)
+ 2023-04-23
+ 更新链接
+ 代码块里的链接不会更新,也不会出现在出链反链面板里,图谱里也没有,[20230419](20230419.md),但是利用这个插件可以不在代码块中写,所以很好用
[quote2code(timeline)]
[line-3, body-2]
2023-04-22
发现
发现了一个新插件anyblock,https://github.com/LincZero/obsidian-any-block/
2023-04-23
使用
很好用,解决了大问题,尤其是很多插件都是用代码块来渲染的,比如ad,比如timeline
2023-04-23
更新链接
代码块里的链接不会更新,也不会出现在出链反链面板里,图谱里也没有,20230419,但是利用这个插件可以不在代码块中写,所以很好用
==但是这个每一行都要写一个> 真的很烦,强迫症看不得这些 所以我希望通过全局选择器或者title实现,还有就是一定要在阅读模式下生效==
就比如我写成下面的样子,遇到下一个标题就是结束,能渲染成timeline的样式: [title2code(timeline)]
[line-3, body-2]
2023-04-22
发现
发现了一个新插件anyblock,https://github.com/LincZero/obsidian-any-block/
2023-04-23
使用
很好用,解决了大问题,尤其是很多插件都是用代码块来渲染的,比如ad,比如timeline
2023-04-23
更新链接
代码块里的链接不会更新,也不会出现在出链反链面板里,图谱里也没有,20230419,但是利用这个插件可以不在代码块中写,所以很好用
标题选择器的默认行为是,选中选择器标识下一个标题级别往后的内容,直到出现比该级别大的标题(你说的意思是直到出现该级别的标题为止)
即做法应该是:三级标题下增加一个临时的四级标题,然后选择该四级标题
### demo
[title2code(timeline)]
#### only Selector
为什么直到比该级别大的标题出现结束?而不是直到出现同样的标题级别结束?
一是为了对应列表选择器逻辑
二是因为选择器会将标题本身包含在选择范围里,会导致你的那个标题缺失
# 1
[选择器,让内容转代码块]
## 2
aaa
## 3
## 4
就会变成:
# 1
```
## 2
aaa
```
## 3
## 4
而非
# 1
```
## 2
## 3
## 4
```
后者将多个同级标题一起消除,级别结构是不变的,但前者会导致级别结构的改变,是一种很怪异的行为
其实在设计之初还有一种选择器设计:
在标题后使用,选择器往上查找标题的等级,选择范围直到遇到等于或大于该标题的等级
这种设计我认为是很好的,也很好用。其实我本来更青睐这种设计,但也存在一些问题:
至于说到的链接问题,是obsidian-api的一个函数说导致的,用他那个render函数会导致 链接、相对路径图片,这种出现问题。
该问题在23年11月得以解决,旧api被废弃,使用新的api。导致的图片问题我检查过是已经解决了,导致链接出现问题的话,我还没验证
653e6109df8be088ce229cdefd23542af38d3a5a
新的选择器语法、和“标题内”选择器,这两者暂无计划做,可以使用我说的在标题A下新增一个小一级的标题B,并选择的方式临时解决
今天才有空测试,大致符合设想了,现在还有两个问题 第一是阅读模式也生效(这个看了最新的issue,后续就会实现,期待ing
第二是关于下面的解释,还是觉得不符合直觉,我的直觉是遇到同级标题就结束比较合理 我就是觉得按照逻辑上,一个标题的范围来选择就好了,不明白为什么我只在一个标题上写了[title2code],但是影响了不是它的范围的内容
为什么直到比该级别大的标题出现结束?而不是直到出现同样的标题级别结束?
二是因为选择器会将标题本身包含在选择范围里,会导致你的那个标题缺失
后者将多个同级标题一起消除,级别结构是不变的,但前者会导致级别结构的改变,是一种很怪异的行为
当然开发者有很多考虑,不管是技术实现上还是整个插件设计上 我提出我的意见,开发者可以选择采用或者不采用,不采用的话我就自适应插件😊
最后提一个想法,我不单独开issue,因为只是想到了提一下,并不是对插件提出功能需求,开发者不想做完全可以不管
下面是某次我在群里看到的某个想法,因为感觉和any block有点像所以记了下来,可能表述很不清楚
如果套用anyblock的逻辑,就是某个md文件作为一个选择器,可以给其附加一些效果,标记的话采用文件名或者property的方式
有点像是 minimal 的那个 list-cards 标注?
这是某个群友的图:
其实 anyblock 如果不加新语法,用原有的语法也差不多
虽然不是不可以,并且看起来感觉还行。
不过AnyBlock优点还是任意选择一片区域,如果选择范围是整个md文档,其实没那么好用。
这种场景下,感觉还是在md头部写metadata的写法更加通用,并且后者很多主题也都是支持的,像Minimal、BlueTopaz主题等,没必要用AnyBlock。
AnyBlock更趋向于你要在整个文章中非常方便地选择一部分进行处理,这时AnyBlock更方便:
是有点像list-cards,但是并不完全一样
我其实最开始的目的是,很多插件可以用代码块包裹一些特定格式(里面不写代码,而是一些文字内容),然后渲染很华丽的效果 但是用代码块包裹后,ob里的出链外链图谱没有了
而用这个插件,比如我用quote2code,还能渲染效果,而且链接也保留着
我就是想借用那些插件华丽的渲染效果,很多效果是单纯的css做不出来的
能描述得详细一些吗