Notepad++插件开发记录

nicker08

已于 2022-02-26 16:30:09 修改

阅读量954

点赞数 3

文章标签： notepad++

于 2022-02-26 16:07:33 首次发布

本文链接：https://blog.csdn.net/nicker08/article/details/123150385

版权

这周头脑一热，花了几个晚上的业余时间，做了个notepad++多目标搜索插件，做好了，但没按原计划上传到官方插件库因为发现是“发明轮子”，计划夭折，投入和聚集的能量即将熵增至消逝，我想分享出来好了，还有点参考价值。

事情始于最近分析的log有点多，主要是设备的resume过程，那必然要看平台上电、亮屏时间点、设备本身启动到就绪的过程，这些log由不同模块打印出，各有各的log标签，我需要把它们搜索出来放到一起，看时间消耗在哪，以便对症下药做优化。

但常用的文本工具都只能搜索一个标签，当然可以用文本替换的方式让他们有共同标签，这样一搜就都出来了；也可以写个如shell或python脚本来处理，但我想，直接用插件实现带UI界面的多目标搜索，那多方便，于是计划立刻启动，做一个能有机会被全球用户搜到和用到的小东西！

编译、了解插件架构和函数入口、获取当前文本、标签匹配、输出文本，几个晚上折腾一阵，就基本有个样子了。

这个按钮放在左边，是因为这个窗口可以合并到边缘，我个人喜欢放右边，这样可以把它缩到很小，仍然可以点到Apply按钮，尽管这样有点奇怪。

这样，最基本的功能的做好了，点Apply应用，结果输出到右边的新建标签里：

最初没考虑效率问题，随意的想法是读出当前文档的所有字符到buffer，以\n分割为行，用memcpy把该行拷贝到一个新buffer，在新buffer里用strstr做匹配判断，匹配则保存到新buffer。这样实际现象是界面卡死后闪退，debug发现是卡死在memcpy，没想到，也搞不定。

后来改了思路，不做拷贝，按行逐个字符匹配，匹配到了才整行拼接到结果buffer，一下就搞定了，效率高了无穷倍(卡死vs 1秒出结果)! 力扣对时间复杂度的龟毛要求诚不欺我！

基本搞定了，非常开心，效果也很好，把它上传到官方插件库，让全球notepad++用户能搜到和用上我做的插件，才是目标！

但，还有一个bug没解决：菜单里有个消不掉的分割线，查了很多资料无果，只能到官方论坛求助，老外很热情，问题很快就解决了，就又顺便问了个问题：我要怎么做才能把我的插件上传到官方插件库？又得到了解答。然后就有人提醒了我一下：

OK，所以我的插件可能会被拒绝或者已经存在了？可能吧，我开始动手的时候，并没有花很多时间搜插件管理器，详细确认这样的插件是否已经存在，只是搜了“text”“filter”“multiline”之类，觉得没有，就动手了。

他们建议我“work smarter, not harder”，最好先问“Hey, is there a way or plugin to do ‘X’?“，我一问，damn！还真有！

这个Analyse插件确实还不错，我想我没必要把自己的初级版本上传上去了吧？

不过值得一提的是，经过实际测试，同样100MB的log，大小写敏感，5个搜索标签，Analyse搜索耗时32秒，我的MultiSearch耗时2秒，这点还是比它强的。

只能说没做足够的调查就直接开始，不过好在没有花很多时间，学到的经验是做多点前期调查和和别人沟通吧，另外实际体验了不同逻辑实现方式的效率区别。

目前代码在GitHub上开源：

把release目录下的MultiSearch-v1.0.dll重命名为MultiSearch.dll，放到notepad++安装目录下Notepad++\plugins\MultiSearch\MultiSearch.dll，重新启动notepad++即可体验。

关注