回 arch7819：
4：使用负数 margin 和 z-index 属性配合可以不影响原有布局的。
5，6：与其大动干戈去修改指示方式，我考虑过之后觉得，不如在停用／恢复一个关键词的高亮同时更新分布图，只需要让分布图绘制函数作一下调整就可以了；毕竟这个脚本是为了高亮和找到关键词，而不是分析关键词在文章中的分布。
8：脚本已经提供了停用自动高亮的开关，而且不影响手动高亮。看来将这个开关做入 GM菜单 是有必要的；也可以考虑在 Ctrl-/ 时自动获得关键词。或者考虑加个“设定”按钮。
9：这……我没看明白你想表达什么……反正这也不是近期将考虑的事情，有什么好的解决方法我就再欢迎不过了。

4. 自动隐藏/显示会引起 宽度变化, 整体的显示出现移动, 吸引了注意力.

5,6. 点击搜索词或在搜索词上滚轮的时候有 "下一个" 的效果, 如此垂直指示器吸引了太多的注意力. 通常, 高亮词的"横向分布" 是比较不重要的, 因为网页都是一屏整行的, 高亮了一眼过去一目了然. 而"纵向"由于看不全所以比较需要指示. 分布图是针对所有词, 在点击特定词的时候, 特定词的分布放到滚动条边上就很直观.

8. 自动高亮的缘故, 我在google搜东西, 它直接自动高亮了所有字词, 页面花花绿绿了很不和谐.... 延时有个好处就是可以先看第一屏, 看完第一屏还没动作(大概需要3-5秒左右), 脚本就高亮出所有来帮助用户.

9. 可以考虑 /abc/i  就是正则表达式,
"abc abc" 是在查找
abc abc
/"abc abc"/ 是在查找
"abc abc"
123 "abc abc" /[a-z].*\d/ 是在查找
123 和 abc abc 和 azzzz3

回 arch7819：
（按段数）
1：嗯
2：这个我已经想好了，跟你想的一样
3：我想用边框变化，或者白色，或者两者结合，看哪个效果好
4：这个恐怕不够直观吧，我觉得自动隐藏复选框比较好接受
5、6：我觉得现有方式就挺好；对超长的网页来说分布图的确比较鸡肋；在悬浮在一个关键词上时显示垂直指示器、手动点击打开分布图这样的设计可以考虑。
7：密集地高亮同一二字中文关键词 2799个，用了 5.7 秒，取消这些高亮用了 3 秒，CPU 是 C2D 2.4GHz（Firefox 查找功能的高亮全部用了 1.2秒）。如果遇到这样密集地重复一个中文关键词还去手动高亮它的话，（就不说了）；如果是自动高亮的，那（情况不好说，反正概率也太少了）。对于标点符号同理。对于英文字母，脚本已经早就添加了过滤1~2个字母的短字符串的功能和选项，默认过滤单字母和单个数字，其他同此条第二句。
8：不需要高亮的话直接点“X”即可；我想象不出需要延时的理由。
9：这个我不清楚；我有这样的打算是因为原脚本对引号括起的关键词处理不好，正则也只能单独输入而不能跟普通文本一起。有更好的解决方法吗？

UI上我的意见是尽量减少浮动框占用的面积.

按钮按  X O/F L/U E/S 排列, 比较具有逻辑性. 另外这四个最好一样大小, 间距也可以小点.  

以颜色来代替搜索词是否激活, 灰色是未激活, 而彩色是激活的.
 
合并结果计数和选择框, 在鼠标移到词上的时候, 不显示计数而显示选择框.

在点击某个词的时候, 将该词的位置在右边的滚动条上用三角形标出来(如果数量非常多, 优先标出当前位置前后的100个).

高亮位置明细仅在用户点击浮动框的非搜索字词位置才显示.  在用户点击字词查找的时候大片的灰块吸引了过多的用户注意. 此时用户的焦点本不该在这个上的.


关于程序逻辑:
有时候用户出现误输入或特殊情况, 比如搜 "e" "中国" 这样的, e 将产生非常多的搜索结果, 相信处理上也会占用很多时间. 设置一个限制(比如1000), 超过此限制的词将不被处理, 以保证网页可响应. 同理, 高亮的处理部分也设置一个超时时间(比如10秒), 以保证不卡住网页.

延迟启动高亮, 有时候并不需要高亮(比如就一屏或结果很少), 延迟N秒(比如3), 如果在N秒内有点击事件(不管点的是哪儿), 高亮就不启动.

都用正则表达式的话可能有性能问题, 正则表达式适合处理的是逻辑密集型, 越是复杂平均开销就越低. 而多数的查找都只是简单的. 单单解析一个正则表达式以创建出 re 对象就足以支持 10000 以上的 indexof . (indexof 的底层实现是 REP[-/Z/NZ] [SCAS/CMPS][B/W/D] 的机器指令. 这是专门为字符串比较而设计的原生指令. )

foxfirefox：楼主应该直接代替查找栏。因为有了这个功能之后，还谁记得查找栏。回到原帖

要代替查找栏就一定要写成扩展，这样的话 XUL /Migemo 就做得挺好了。
我也试过用 User Script Compiler 来将 EWH 转成扩展，但结果是失败的。
而且，Firefox 3.6 开始似乎使用了文本流的方式来实现页内查找，证据是新的查找高亮不再修改网页（以前版本的修改查找高亮样式的样式表通通失效），而且对位于不同元素中的文本也能一起查找，如

<em>微软</em>公司

仍然能查找到“微软公司”，而我那脚本是无法这样做的。
我目前只能尽量先优化现有的 GM 脚本，直到不使其扩展化就不能进步。

foxfirefox：楼主应该直接代替查找栏。因为有了这个功能之后，还谁记得查找栏。回到原帖

不一样，EWH是通过搜索栏来使用的，查找栏有查找栏的用处。虽说EWH也可以在某些情况下手动呼出，但是并非所有可以Ctrl+f的地方都可以呼出ewh

看着比以前的好

楼主应该直接代替查找栏。因为有了这个功能之后，还谁记得查找栏。

看似不错！！！！！！！！！！