话说有没有示意图说明下，块级元素的嵌入块指的是？

引用嵌入块可以提供直接编辑功能吗？

话说有没有示意图说明下，块级元素的嵌入块指的是？

块级元素就是现在的块，比如段落、列表这类。

引用嵌入块可以提供直接编辑功能吗？

不行。

不能提供直接编辑功能是什么原因？

@zxhd863943427 难以实现。

那之后查询嵌入块还可以用吗？有些时候会需要sql查询嵌入块汇总些文件

那之后查询嵌入块还可以用吗？有些时候会需要sql查询嵌入块汇总些文件

可以用的，不影响，只是 SELECT * FROM blocks WHERE id = 'xxx' 这种格式的查询会同时被计入引用。

终于等到了，感谢 D 大的付出。

D 大，方案2，能实现对页面内的“嵌入块的内容”进行搜索吗？

能实现对页面内的“嵌入块的内容”进行搜索吗？

实现不了，嵌入块本身就是搜索以后的结果了。

一个不优雅的解决方法：能否将嵌入块的结果缓存在备注里，这样就能搜索到了。

这个受搜索开关影响，另外这样的话更新定义块时需要同步更新备注，并且嵌入块的备注就被占用了。

这个受搜索开关影响，另外这样的话更新定义块时需要同步更新备注，并且嵌入块的备注就被占用了。

能否给嵌入块专门设计个容器来缓存嵌入的内容呢？这个容器不显示在正文里，但可以被搜索到。

上面是一个来自外行的天方夜谭的建议，可能不切实际。

目前不考虑做较大的改动了。

目前不考虑做较大的改动了。

期望之后能考虑一下”页面内搜索嵌入块内容“这个功能，

我有个页面是用于整理待办内容的，平时在其他页面工作项目建立的待办事项，直接通过嵌入的行式加入到这个页面，但在这个页面搜索时，第一次页内搜索时，搜不到内容时，只得通过全局再搜索一次，体验很不好。

这个目前找不多解决方案，直接用全局搜索顶顶吧。

这个目前找不多解决方案，直接用全局搜索顶顶吧。

好吧。

刚开始列的方案1是麻烦了，但一是可以添加更多如搜索、直接编辑等功能，二是以后改的成本更大，距离拥有真正的嵌入块越来越远，所以还不如这次就直接考虑方案1，功能推出时间可以放的远些，不必这么着急。

总之，祝思源越来越好吧。

还是希望 D 大能在这次考虑使用方案 1，设计一种真正的嵌入块，功能推出时间可以放的稍微远些，不必这么着急。因为若是以后改动的话，成本会更大，原因如下：

1. 在这次修改之前，由于嵌入块没有反链，所以嫌弃没反链的人压根就没在笔记中使用嵌入块，实在需要嵌入块功能的人在使用的时候自己手动打上链接作为反链提醒，没有手动打反链的人在使用过程中也在心理上默认将嵌入块作为SQL 查询来使用，因此在这次设计出“真正的嵌入块”，其实不用考虑以前的笔记数据对新的嵌入块的适配，没有负担。
2. 若是这次推出这种在原来嵌入块基础上修补的带反链的嵌入块的话，由于有了反链，势必会有更多的人在笔记中使用嵌入块，以后想增加“页内搜索、直接编辑等功能”而再重新设计真正的嵌入块时，就需要考虑对之前的笔记中的嵌入块进行适配了，这负担就重了。

综上，希望 D 大能考虑在这次推出真正的嵌入块，这个时间节点刚好合适。

之前加入嵌入块菜单的时候已经有考虑这个扩展变更了，所以菜单上的嵌入块也是使用 WHERE id = 'xxx' 的方式实现，所以实际上所谓的“真正的嵌入块”对于用户来说目前只是少了引用关系，从使用方式上来说，目前这个方案是最优解，而不是再加入新的嵌入块类型。

之前加入嵌入块菜单的时候已经有考虑这个扩展变更了，所以菜单上的嵌入块也是使用 WHERE id = 'xxx' 的方式实现，所以实际上所谓的“真正的嵌入块”对于用户来说目前只是少了引用关系，从使用方式上来说，目前这个方案是最优解，而不是再加入新的嵌入块类型。

D 大，“之前加入嵌入块菜单的时候已经有考虑这个扩展变更了”是不是意味着，嵌入块的“直接编辑、页内搜索”功能还是有机会实现的呢？

直接编辑不考虑了，实现不了。页内搜索的话可能有希望。

直接编辑不考虑了，实现不了。页内搜索的话可能有希望。

加油，期待“页内搜索”，让思源变的更美好。

我觉得直接编辑虽然方便，但是不符合逻辑，嵌入块应该被视为从原块中抽出来的部分，相当于高级的引用，所以使用浮窗编辑我是能接受的，还能查看上下文。

页内搜索相比倒是符合逻辑，且很必要了。

嵌入块支持搜索请关注 #7112