模糊搜索只针对 Listary 历史生效（曾经通过 Listary 打开过的文件）。Listary 历史在最近的版本中做过优化，不再存过多历史，并且有衰减机制。所以理论上来说，不会有大量的文件因为模糊搜索被匹配到。如果被模糊搜索匹配到了，证明这个文件最近被打开过，所以排在前面也不是完全不合理的。
另外，启动器（快速搜索）的主要功能是为了快速打开，我大致知道文件名，也大致知道路径，我期望的是立即打开并使用文件。所以排序是非常重要的，我们要确保目标文件在前 9 条结果里展示出来，所以他的排序算法和文件搜索窗口（完整搜索）里是不一样的。文件搜索窗口更多是查找目的。
以上是对我们设计的解释。但是我们一直在持续优化排序的算法，也很希望听到大家的反馈。如果您仍然觉得不合理的话，还是建议给我们提供截图，给我们一些真实的使用场景。截图里，我们需要看到真实的搜索词，还有前 9 条匹配，这样才能进行针对性的优化。
没错，是WPS预览，辛苦了 
理解了，谢谢。
正因为启动器是为了快速打开，所以它的搜索结果应该力求准确，更不能使用模糊搜索给出过多的结果，否则起不到快速打开的目的，而用户也应力求准确地输入检索关键词以来配合实现精确匹配，准确得到想要的结果便于快速打开。
所以当我在启动器里看到有模糊的搜索结果时，觉得不合理。
截图如下（模糊部分的内部与搜索完全无关），截图中的搜索结果中的1、3、4、5、6条可以认为是正常的结果，其它2、7、8、9完全没理由出现，7和8似乎也不符合模糊匹配规则吧。
感谢反馈。在这个截图里，搜 zhyh 的时候，你想要搜到哪条结果，它是否在前九条呢？我看你的搜索结果，我猜测，大概率已经排在了第一位。这种情况下，其实我们目的就达到了。我并不认为当前这个例子里，排序是差的。不过我会记录下你的需求，会考虑给模糊匹配权重降低。
至于 2-9 为什么会出现，因为很多时候，用户对一个文件名的记忆是不清晰的，记忆是一截一截的，2789因为是曾经打开过的文件，我们觉得很重要，会尝试模糊匹配。我认为，只有这些文件导致你想要找的文件在后面，甚至排不到前 9 位，才能真正称得上负面作用。有的时候，有些文件就是想不起来叫什么了，这时候如果有模糊搜索，我认为是很救命的。不是所有用户都“力求准确”的输入检索关键词。很多人都是想要什么就输入什么，在输入框里加入路径等等。
另外，你说的 78，因为文件名太长了，后面没展示全，我猜可能在后面匹配上了。
搜索结果的第一条就是我想要的；既然准确匹配到了想要的，就不需要那些模糊的不大可能是想要的结果带来的干扰。
虽然我们经常记不清一个准确的文件/目录名称，但是会记得名称中的准确的几个“词汇/词组”，比如当我们输入“zhyh“时，是很自然地将它当成一个词组的。如果用户认为他记忆的是名称中的三个词/字，他应该输入“z hy h”三部分，这是自然而然的语言习惯，所以我认为不用把那些输入“zhyh”的当成是想要输入“ z hy h”的。而没有这种语言习惯的用户（应该是少数群体），也应该学习/了解下listary的搜索语法，这样他也能精准搜索。
我提建议是基于上述的考虑；）
现状也是非常令人满意的~
上周通过邮件反馈了，是否有收到？能否确认到实际问题？有没有解决办法？
收到了，非常感谢！能够定位到问题，是能够修复的。
接下来的这个更新，我们优化了很多内容，还在反复测试中，测试通过后就会发布。
可以等以后，遇到了想要的文件没有排到前面的时候，再给我们反馈～那样会更有针对性一些。
Listary 已更新至 v7.0.0.9 beta，检查更新就能收到推送～更新日志：Listary V7 来了 | 全新启动器推荐、多选与重构引擎
这个版本大幅提升了稳定性
持续期待并等待中——“自定义关键字快速打开目录功能( 缺少自定义关键字快速打开目录功能 )”
能不能添加预览面板自动弹出的设置，不需要每次都按Alt+p.
swiftlist工具的开发者的号被github封了，是不是listary给搞的？是不是因为抄袭listary了？
我是 Listary 作者，都是老用户了应该了解我了，我们不接受这样的诋毁
我专心做 Listary 已经 16 年了，人品和口碑是有目共睹的，坚持原创功能并持续用心打磨，坚持较低的价格并付费永久买断。因为各种原因有段时期更新较慢，有些用户有所抱怨，我们也理解。我们最近调整了研发节奏，更多精力投入进来，并且有非常大的更新在路上。
我们一直在专心做自己的事情，对 SwiftList 没有关注和任何行动，除了去 Listary 论坛发布的一些宣传帖子给隐藏了。另外了解 GitHub 的朋友应该知道，即便是有版权投诉，也是先通知作者，或者隐藏仓库，而不会对账号有操作。
希望大家保持理性，用自己喜欢的产品就好了，别这么多恶意揣测。
Channing
Maker of Listary
已经开发了预览面板常驻的功能，但是感觉现在预览还不够稳定。我们内部测试的时候，感觉预览面板常驻更多是负面作用而不是正面作用，所以这个功能并没有合并。
等以后预览更加完善的时候，会考虑增加这个功能的～
了解了。
我v4就是listary的付费用户了。listary十年没有大的体验提升和更新了，当我看到Swiftlist 就像抓住了一根救命的稻草。当然我希望这两个工具都有各自的发展和用户。虽然不怎么像以前那样向listary提需求了，也不希望listary就落寞下去，而且现在你们在更新，毕竟这是当年我向发烧友推荐的搜索工具，而且陪伴我十多年，实大实的提升了我的搜索效率。
哈哈别着急，一定会做的，就是没有那么快。
因为 v7 的引擎是重构的，所以我们前面会更关注于提升稳定性，修复 bug 等。7.0.0.7 和 7.0.0.9 都是对稳定性的提升。
我们接下来还会对一块进行重构，大概在 1-2 周后发布。发布后，也会先观察一下用户反馈，进行一些 bug 修复。
再然后才会增加新的功能。
我的软件是最新版本，我在使用软件过程中当我在一个软件内选择上传文件，在弹出文件选择框时选择框的底下会出现Listary的最近打开文件选择框，但这个框的大小只有图中红色框选所示，长度和文件选择框不一样个人觉得不够美观和优雅，希望长度设计成和文件选择框一样且会跟随选择框大小的改变而改变。
反馈两点需求，一：在另存为对话框，我很多时候想去文件夹但是不记得文件夹名，因此会搜索文件夹内的文件并按Ctrl+Enter到达父目录，但是这样的话我的文件名就变成我搜索的文件的文件名了，这个是否有办法解决？二：调出启动器时，按上方向键会调出上一次输入内容，但是按第二次就成向上了，我记得原来一直按上是会调出更早的输入内容的。(PS：一般也不会按上方向键调出上一次输入内容后通过上方向键去寻找内容吧，要找也是用下方向键)
还有个细节问题反馈一下：更改窗口尺寸，上下宽度减小到一定程度后，“关于”的图标就隐藏起来不见了，建议加滚动条或者增大所规定的最小宽度尺寸
