Return document blocks when the keyword search hits different block content

[LoneFireBlossom]

目前搜索文档块（往往）不能通过搜索正文内容搜索到，所以希望支持「搜索命中不同块内容时返回文档块」

Is there an existing issue for this?

• I have searched the existing issues

Can the issue be reproduced with the default theme (daylight/midnight)?

• I was able to reproduce the issue with the default theme

Could the issue be due to extensions?

• I've ruled out the possibility that the extension is causing the problem.

Describe the problem

设想这样一个场景：
我在思源里写了一篇文章：

# 思源真好用

它支持富文本编辑。


它支持块引用。


它支持标签。

……

渐渐地，我在思源里写了很多很多笔记。然后，我想找这篇文章，于是要搜索，要多加关键词。
于是我搜索“富文本 标签”，发现竟然搜不到！
这就很尴尬。

再比如，根据用户指南，「整个文档是一个块」：

标签用于对块进行标记：

我对文档块设置#think#标签，然后搜索#think# 和文档块正文中的内容，搜不出该文档块。

希望能实现的效果

最直接的想法是，希望在搜索时，如果搜索关键词位于文档块里的好几个块，那么这个文档块就应该出现在搜索结果中。

真正实现起来的话，为了搜索结果尽量不要重复，可能得实现得麻烦一些，也就是说，如果搜索结果中还包含这个文档块中的任意结果，那就不要在搜索结果中出现这个文档块。
换句话说，如果搜索结果中不包含这个文档块中的任何块了，但是整个文档块还包含搜索关键词，那么此时再在搜索结果中出现这个文档块。

[LoneFireBlossom]

搜索类型我都开了。

不过我又试了试，我这个issue涵盖面很广啊……
思源是不允许搜索文档块里的内容吗？这样也搜不出来。那文档块怎么能称之为“整个文档是一个块”呢？

[88250]

标签测试正常：

后面一个是不支持搜索内容的，社区里搜索一下，有个比较复杂的 SQL 可以支持。

我先关闭了，如果还有问题请继续跟帖，谢谢 🙏

[LoneFireBlossom]

标签测试正常：

后面一个是不支持搜索内容的，社区里搜索一下，有个比较复杂的 SQL 可以支持。

我先关闭了，如果还有问题请继续跟帖，谢谢 🙏

是标签+内容搜不出来啊

[LoneFireBlossom]

标签测试正常：

后面一个是不支持搜索内容的，社区里搜索一下，有个比较复杂的 SQL 可以支持。

我先关闭了，如果还有问题请继续跟帖，谢谢 🙏

整个文档是一个块，结果搜索这个块里的词语搜不出这个块，这根本就不合理，不是SQL支持就完事儿了啊……

[LoneFireBlossom]

这个问题核心是文档块在有些地方是包含正文的在有些地方不包含，得解决啊

[88250]

不解决了，设计如此。

[LoneFireBlossom]

不是啊……无论拿出什么理由来，这就是个BUG而不是feature啊

[LoneFireBlossom]

我们来看看什么是容器块：
容器块可以包含其它块，也就是说里面的东西都是属于这个块的。
D大你说「设计如此」，上面这是不是「设计如此」呢？当然是啊。

我们来看看其它容器块是什么样的：
经过测试，列表块、列表项块、引述块、超级块里的内容全都可以搜索到，都是符合设计的，
只有文档块不行！这不符合设计。

[LoneFireBlossom]

这是列表块：

这是列表项块：

引述块：

超级块：

怎么文档块就不行了呢？这不符合设计啊。

[88250]

文档块比较特殊。

[LoneFireBlossom]

我依旧不理解。
我想写一篇普通的文档，事后想要用关键词搜索这个文档，岂不是会陷入“越加关键词越搜不出来，减少关键词的话又看到一大堆无关内容，在搜索结果的海洋里找不到东西”的困境。

比如这个文档。

我搜两个关键词就搜不出来，这是不是有点过分了。

在我的理解中，文档搜索是基础中的基础……

[LoneFireBlossom]

所以……开发者认为用户不应该进行文档内的关键词搜索？

[88250]

搜索毋庸置疑很重要，但是现在确实不好解决，只能考虑用 SQL 顶顶了。你如果有技术方案可以提出我们讨论看看，谢谢。

[LoneFireBlossom]

哦，原来是技术问题啊，我还以为是设计理念不一样…
那没事了。

[LoneFireBlossom]

还有一个问题啊，对于这种未来肯定要解决，现在是因为遇到了困难，或者优先级别不是那么高，所以搁置的问题，真的关闭这个issue就好了吗？我觉得是不是用一个其他的方法更好。比如说虽然关掉了这个issue，但是打上一个future plan之类的标签。

[LoneFireBlossom]

如果只是关闭了这个帖子，而没有做一些备注或者统计的话，以后可能会忘掉其中的一部分提议。我开发者可能会忘掉，用户可能也会忘掉，或者流失了，不再提这个建议了。

[88250]

好的，我们保持打开，后面看看有没有方案可以实现，也欢迎大家帮忙，谢谢。

[LoneFireBlossom]

我目的不是说仅仅把这一个issue打开，而是需要标注所有「值得后续优化的问题」issue。但如果这种issue都保持打开状态的话恐怕不符合开发者的习惯吧，我看思源的issue区，open状态的很少，和某些攒了上千个open issue的项目很不一样。
所以可以考虑加标签这种方式，等大工程都搞得差不多了再从关闭的带相关标签的issue里随机抽一些拿出来研究怎么改进

[88250]

保持打开收集反馈看看，如果需要的人多的话再考虑下一步措施，谢谢。

[LoneFireBlossom]

好的，但是你说的和我说的不是同一个事情啊…😂在 2024年4月5日，18:27，D ***@***.***> 写道： 保持打开收集反馈看看，如果需要的人多的话再考虑下一步措施，谢谢。 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[88250]

保持打开可能更容易被其他人看到，如果需求较多，再提高优先级。

[TCOTC]

我感觉这个应该是大家都有需求的，搜索文档时一般只会对几个关键词有印象，而这些关键词是分布在文档中不同的块内的。

平常搜索时最苦恼的就是明明记得文档里有什么关键词，搜一个词出来一大堆搜索结果，搜两个词又搜索不出来东西了。

[vodecs001]

+1

[LoneFireBlossom]

开发者说这个需求的实现有技术上的困难，我理解。
现在实现不了，但未来总归要实现。搜索功能对笔记软件来说极其重要，我觉得算是“一个笔记软件应该满足的条件”中的T1级别。

比如，设想一个场景，我给别人推荐思源笔记，别人问我，这个思源笔记搜索做的怎么样？我告诉他，搜索功能很好，只是搜文档很有可能搜不出来。如果你要想搜文档搜出来，就得用大纲写。
我觉得听到这话的人，都会觉得很奇葩，理解不了怎么会有这种神奇的情况出现（得明白思源块设计是什么样的才能想通原因）；其中有相当一部分人就不会选择思源了。
至于我用思源、用文档而非大纲的形式写东西，是怀着“未来思源一定会、一定能解决文档搜索”的信心用下去的。

因为我不懂技术所以下面只是我的胡思乱想：
既然现在实现不了、未来一定要实现这个功能，那么我觉得最好在这条路上尽量避免“会对未来实现这个功能造成困难”的软件设计。

[TCOTC]

我认为样式可以像 按文档分组 这样，返回文档以及匹配到关键词的块（如果只返回文档的话也不知道自己搜到的是什么块的内容）：

[SaXz2]

可以参考上图插件 「基于文档搜索」

[88250]

要不咱不改了，用插件吧 😂

[TCOTC]

别，我不想装插件

p.s.我已经在尽量去插件化了

[88250]

v3.1.11-dev2 已经打包完毕，各位帮忙测试一下。

目前这几个块式编辑应用 Notion/Wolai/FlowUs 都没有支持跨块搜索，我觉得我们暂时也可以不动，因为社区插件已经解决了这个问题，如果要在原生中支持，新添加搜索方式比较合理，但是也会带来其他问题（比如无法支持搜索替换）。

这个改动目前我还是持保守意见，先不要做改动了。

[TCOTC]

搜索方式 全文关键字 的情况下屏蔽替换即可

p.s. 我认为叫“关键词”更合理

[MisakaImouto8912]

试了下 v3.1.11-dev2 ，我只希望如果上这个功能，可以给一个开关，我数据库 19w多行，每次查询 2.4秒多，体验很糟糕，我个人来说的话，如果有需求，还是会用插件。。。插件0. 4秒左右。

[88250]

@MisakaImouto8912 感谢反馈，稍后的版本会继续尝试优化。

[88250]

目前参考 基于文档搜索 代码实现了一下，性能问题已经解决。

稍后发布 dev3 大家版本测试看看。

鸣谢 @Misuzu2027 ❤️

[TCOTC]

今天搜索了几次，文档全排在前面确实比较难用。

如果不新增搜索方式或者开关的话我感觉这样排序搜索结果会合理一点：

1. 标题匹配到关键词的文档块
2. 其他匹配到关键词的块
3. 文档内容匹配到关键词的文档块

不过我认为新增一个搜索方式，像 按文档分组 那样返回文档以及匹配到关键词的块会更合适。能看到文档匹配到关键词的是哪些块，比只看到一个文档标题更好判断。

[88250]

排序方式已经改了，等发布 dev 再试试，我觉得现在已经比较好用了。

[TCOTC]

@88250 目前是只有多于 1 个关键词的情况下才会搜索并返回包含对应关键词的文档吗？

只有一个搜索关键词的情况下不影响原有的搜索性能，感觉合理很多

[88250]

一个关键字也是新的实现逻辑，性能和之前没有差太多。

[88250]

考虑了下，单关键字的情况下还是走 FTS 搜索。

[TCOTC]

1. 我觉得显示匹配到的块数会方便一点
2. 匹配到块数多的文档应该排在前面

[88250]

我没法实现匹配到的块统计和排序，有人有方案的话可以帮忙 PR。

[cordinGH]

我没法实现匹配到的块统计和排序，有人有方案的话可以帮忙 PR。

关于块统计，或许可以参考一下插件 「基于文档搜索」，该插件基本实现了这个功能

[Wetoria]

如果我希望“测试”能搜到“测什么测，试试这个”这句话， @88250 你会不会打我。