feat: 在输入未被识别的命令时查找用户最可能想输入的命令

[Ace-Radom]

Done, Request Code Review

Link Issue: #33

现在只有键入 /help 才会打印帮助页 别的时候不会了
在出现未被识别处理的命令的时候会去命令列表里搜索有没有可能的 有的话输出最相似的那个
但和我那个重构项目里处理逻辑不同的是 我没有改动”命令开头匹配“的机制【重构计划里改成强制匹配第一段了】也就是说会出现这种情况：

但我觉得这样没有什么不好 所以就没改【毕竟开头匹配都能匹配上那用户也应该知道自己打的啥】

同时这个算法我在Issue里也说了是把levenshtein和jaccard结合起来的 不用Sorensen Dice算法或者levenshtein或jaccard单用主要是因为每种算法都有一定局限性 举个例子

/            -> /raw (levenshtein only)
/war         -> /raw (jaccard only)
/tawimaeoaut -> /raw (sorensen dice only)
// 这里他应该输出/timeout的 但sorensen dice匹配最长子串的算法会把他匹配到/raw上
// 因为他和/raw /timeout之间的最长相同子串长度都是2 但是/raw在计算比例时分母更小 算出来的相似度也就更高

所以我最后选的就是levenshtein距离最短的且两者jaccard相似度大于75% 结果就是

当然这种算法也代表着在遇到错的离谱的命令会无法匹配 你可以考虑一下在这种情况下要不要输出help page

[xiaoxx970]

用这个：

v = [[0 for _ in range(s2_len+1)] for _ in range(s1_len+1)]

就不需要引入numpy了，我测试了结果一样，你可以试试看

[xiaoxx970]

List comprehension time: 0.00769679102813825
Numpy time: 0.0005205830093473196

虽然numpy比这个嵌套循环快了10倍，但是我们还是节省下用户安装numpy的时间吧

[xiaoxx970]

”命令开头匹配“这个确实是可以是feature的bug，我也是才发现，等之后有精力重写命令匹配部分的时候再考虑更好的匹配方式吧

[Ace-Radom]

虽然numpy比这个嵌套循环快了10倍，但是我们还是节省下用户安装numpy的时间吧

确实 而且这个数据量numpy的速度优势在体感上也基本没有

”命令开头匹配“这个确实是可以是feature的bug，我也是才发现，等之后有精力重写命令匹配部分的时候再考虑更好的匹配方式吧

是的 我也是在隔壁用strncmp匹配测试的时候意外发现的 然后我那里的解决方法是在匹配开头就执行一次分段 把一级命令单独提取出来匹配 在需要用到二级命令的时候再匹配整个命令 你可以考虑一下