目前为止唯一提供了有用信息的回复。谢谢你。

如果我没记错的话，之前 D 的签名是“基础不牢地动山摇”。

那“复制粘贴”的体验，应该算是一个文本编辑器的基础了吧。

Block 才是那个锦上添花的东西。

现在“复制粘贴”的体验有点奇怪，期待改进优化。

我不认同你对于第 4 条的观点。

以 block 作为笔记内容的“检索”和“引用”的基本单位，的确是思源的特色，请保持。
但是我的建议是，复制时应以字符作为基本的“选中单位”，实现“准确”的复制。
这是两回事。

也就是我选中了多少，就可以复制多少；
而不是我选中了多少，自动扩展到最后一行所在的整个 block。
尤其是这个 block 非常大的时候，体验非常割裂，非常反直觉。

以下图为例：

当我只想复制到 777 一行时，实际复制结果是一直复制到 999 一行。
即第 777 一行的父级 444 行及其所有子级内容都被复制了。
这还只是一个随手写下的简单例子。
如果是一个非常大的 List 呢？
比如一个大纲笔记《幕布》迁移过来的新用户呢？
很可能笔记通篇就是用 List 来组织的。
那得多复制多少内容？

而且，这是存在于引用、代码、段落等所有块级结构中的通病！
而且，这个通病发生在用户最常用的功能上！
尤其是对于有大量复制粘贴需求的新用户，5 分钟之内就能发现，开幕雷击属于是。

对于任何文本编辑器的用户来说，选中多少复制多少，都是第一直觉。
如果内容不太多，即使多复制了额外内容，也可以当场检查出问题；
但是如果内容多到来不及检查呢？那给用户的感觉就是，你这个软件多少带点雷。

如果说其它几条建议是关于《跨页复制》，那第 4 条则是强调《跨块复制》的功能异常。
两者有所联系，但并不完全相同。

当然，页面加载不全导致的复制不全，也好不到哪儿去。
作为一个文本编辑软件，居然连 Ctrl+A，接 Ctrl+C，接 Ctrl+V 这一套连招都会失效，确实是有点惊世骇俗了。
至少，同生态位的 Obsidian 没有以上这 5 个问题。

如果是技术上有难度，大可慢慢想办法。
但是当作 Feature 的话，那就实在太奇怪了。

其实还有一种实现方式，就是当直接粘贴 URL 的时候，思源在后台去访问这个 URL，获取页面的 title 标签当作链接的文本，然后给用户一个提示是要直接粘贴 URL 还是当作链接插入笔记中。

不过这种做法可能需要用户授权。

果然有人提出这样的问题

添加链接时，由其他应用返回思源会失去焦点 - 链滴
添加链接时，由其他应用返回思源会失去焦点

默认在列表中折叠这部分就可以了啊。

• 没有开关
• 引用数对得上
• 低权重内容不占用用户心智
• 提供低权重内容的用户可达性，而不是直接删除

啊这…

这不巧了么…

Typora 里图片的缩放就是通过 <img> 标签实现的啊…

Typora 的用户基数还是挺大的，如果不能在导入的时候完美兼容，感觉很亏啊 D 大！！！