思源自己不能，或许插件可以。

这可能是在同步，第一次全量上传很耗时的。

思源并不适合记这种类型的笔记，你需要使用带有白板支持的笔记软件，或者你需要修改自己记笔记的方式。

比如说写成：

The designer pushed him by design,making him annoyed
designer: 主
pushed:谓
him:宾
by:介
making:动词+ing

你要学会把图形信息转变为顺序结构，要不你就只能自学 html 块硬写了。

我认为功能迭代快是因为功能少所以爆改不用担心 bug 循环，意见反馈迅速是用户少还可以挨个看一遍并且不用担心用户需求冲突。

客观来说只要功能数量和用户体量达到思源这个量级甚至更少一点，那迭代和反馈的表现总是差不多的，毕竟人力有限，这个开发者还更少，目前只有一人。

来自 tiddlywiki 的奇怪方案。

看看 D:/科研/book/SiYuan 的截图？你这看上去是把笔记塞在安装目录下的效果啊

很简单，刷新一下思源就行了。

建议使用插件 开发者工具 的重载窗口功能。

F 佬这一波操作是直接达成我想实现的效果了

尝试减少输入字符，并使用空格分隔，如“风 华 公 交”

需要传递搜索结果给思源，那就有点难写了。

为知能解决问题，那就挺好的呗。

感觉可以建议一下官方，在订阅用户使用自定义 s3 的时候也能使用官方的同步感知。

@88250

去看看正儿八经的开源多维表格吧，apitable、nocodb 之类的。

简单节点参考 思源大纲笔记模式的性能测试

已知 bug，上一次的搜索结果没完全清除，可以输入空格强制刷新

开发者动力不足

这个主要是指开发者觉得使用者需求不足、不统一，而宁愿花时间在其他问题上的状况。

开发者不上容量

这个我倒是大大赞同的！为啥扩容变成这种离谱的方式……要是按一年 8g100 块这种容量包卖不好吗？非得变成大容量用户统一转第三方 S3……

反正我这方面是坚决反对开发者现在的方案的。

因为很简单，插件可以写的随意、垃圾且不稳定，但本体不行。

假如我作为一个想给思源增加功能的开发者，我首选会写一个 js 代码，其次是插件，如果做不到，我会考虑向官方要接口，最后才是直接修改本体。

因为社区开发者和官方都不愿意给自己增加维护的负担，社区开发者最希望是遇到问题 you can you up，而官方维护本体就已经筋疲力尽了。

举个例子，长啥样的 html 形式的 img？

嗯，你说的对。我使用思源的历程，大概可以概括成：《前端：从思源到入土》

不过说说具体东西吧。

1. 移动端：这个不用说，不好用众所周知，但人力就这样限制，等明年吧。
2. 双击打开：原来就是的，到底是谁提议改掉的！目前处于很多人想改回来，但开发者动力不足的阶段。
3. 移动端桌面模式：我觉得这不能算常规需求的说……除了思源没有哪一家需要移动端改成桌面模式。
4. 嵌入块：还好吧，动态查询有已经比没有强很多了，但是做查询 UI……我觉得连移动端优化都抽不出时间就别提更少人用的东西了。给个简单点的小目标，能用“and or not”这些查询语法怎么样？

浏览器上大概都不行，因为使用了 open("siyuan://block")，换个跳转方案也许可以试试。

点个 star，不过这东西咋用？

我对于功能理念之类都是无所谓的，毕竟大家记笔记的习惯各不相同，所以各有所好。只是说这个东西实现起来并不简单，所以才说是颠覆。

关于移动……这个东西是可以直接搜索过滤的，我觉得这无论怎么说也不能说慢吧。

第一个问题是不够直观，但我挺好奇在这种情况下——指笔记很多的情况下，onenote 有何优势呢？就是它跟你不创建子文档，笔记本作为一级，笔记内容直接就是二级，它的区别在哪？

第二个问题，同上，二级文档树的优势在哪？就是 onenote 会快吗？思源我记得是可以直接文档树右键选择移动进行移动的，对于你的问题，实际上可以先移动移动到指定的文档下，然后再移出来，变为它的上方或下方，OneNote 有什么更简单的方案吗？

你在提出一个颠覆性的要求，虽然在构架上并不是不可能实现，但是你的理由目前在我看来还不是很充足。

分割不是问题，没有合并才是问题。你在 100 个文件里分别打了一个字，结果产生了 100 个分块和 100 个新的文件索引，这属实让人难绷。

分割本身就对应的是大文件，把他们进行分割反而改善速度，利用上多线程下载和上传。

答案就是：节省空间，并且在大文件上传下载时加速。由于每个块只对应一个文件，所以能下载最少的内容到本地快照。由于一个大文件被拆成多个分块，所以能很好利用 s3 在少量大文件批量上传的速度。

数据库和索引是不经过同步的，它们放在 temp 目录下。

调用一堆内核 api 跟很多数据发生变化无关，我指的是打开 siyuan.log，看这一堆东西的上下文：

I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/c4/0294c4d4c1c85d1d3c85d9ad8527c8988d4121]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/c4/0294c4d4c1c85d1d3c85d9ad8527c8988d4121, 561/6604]
I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/cf/5e4f6bad5e4a80d2e2e596b5bb084eb1447915]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/cf/5e4f6bad5e4a80d2e2e596b5bb084eb1447915, 562/6604]
I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/89/24958a3954bd9c8bad705e0f6a03a8d33f6273]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/89/24958a3954bd9c8bad705e0f6a03a8d33f6273, 563/6604]
I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/d9/2c22093eaa028952d2a912f5af45c8a24d0328]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/d9/2c22093eaa028952d2a912f5af45c8a24d0328, 564/6604]
I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/60/3ddb05be9c7b26b7b962eb6bd4948c50a78915]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/60/3ddb05be9c7b26b7b962eb6bd4948c50a78915, 565/6604]

它们就是实际上传下载的数据分块，如果数量小，时间短，那就说明并不是在这一步阻塞的。

我打几个字就是会产生很多小碎片，如果说，用户打了几个字，只动了一个思源文档，但是思源产生了一堆数据块，这个作为一个个人使用的本地软件，不是一种冗余吗？要怪在用户不了解的头上吗？

我并没有说”用户打了几个字，只动了一个思源文档，但是思源产生了一堆数据块“是合理的，只是我觉得实际上并不只是修改了那一个文档，而是不知不觉中修改了多个文件。这些文件的修改当然是要改进的问题，但是这不是同步机制的问题。

在这里的语境中，我指的是建立快照时，产生的数据分块，也就是把文件变动后加入快照，产生的加密小文件。跟思源文档中的块是不同的概念。

这些文件本来就是运行时文件，而思源不通过中间件处理对接，反而放在了同步里面，内核我也看，很多数据发生了改变=很多文件发生了改变？

所以你的运行时文件是指什么，中间件处理对接又是什么，很多数据发生了改变是什么情况？

那我的意思也并没有说思源目前同步的机制在速度上是好的，不然这个标题也不会是”这么慢的探究“了……

我想指出的只是，速度慢的原因与大多数人想的情况并不一样，使用思源这种快照、分块、加密的形式也能达到一个比较好的速度，举了 restic 和 livesync 作为例子。

但是，我最后也得到了另一方面的结论，思源对速度不友好，但是对于空间占用、上下传流量是最友好的。这在另一种层面上，就是要时间还是要空间的考虑，思源的同步机制并不是一无是处的。

你的意思是另一端直接知道要校验那几个文件的索引？这个……其实 livesync 不管这个的。obsidian 也不管 livesync 的，更别说 dataview 之类插件的索引了。它们都是使用文件系统的事件来更新的。确定是那几个文件需要校验确实有帮助，不过目前快照直接进行索引对比也能找出更改文件。这方面的主要问题还是 D 偷懒！没有利用这个信息！

这个可能不是你觉得自己打几个字就真的是几个字了，你得看看实际数据块的数量。实际上真正的打几个字的场景就是开了同步感知进行交替同步，目前我测试的延迟就是 6s 左右。你可能得看看内核日志，确定到底主要在干啥了。