GitHub Community
New search is less helpful than old search for complete matches of substrings #41709
-
Select Topic AreaProduct Feedback BodyThis search finds precisely what I want:
This search technically does but practically doesn't: specifically the results are so cluttered that my eyes miss that the first hit actually has the hit I want: because my eyes scan the first block, see: and conclude "oh, gosh, it's a substring match, this block is useless, let's check the next block".
One way to save me from this would be to use a different color for perfect matches vs substring matches (probably making substring matches a paler color). |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
Thanks for the feedback @jsoref. I like the idea of indicating exact matches better. We could also use it in our ranking. For a technical explanation, the reason why the old search finds "roduct" so well is that it tokenizes whole words and some programming-related separators (like |
Beta Was this translation helpful? Give feedback.
-
|
Thanks 😄 . I've worked on a cross reference (MXR) and am currently working on a spell-checker which is aware of programmer conventions (ala the old engine). It certainly felt like your engine was effectively moving from the MXR model to the OpenGrok model which was pure substring. I can understand why that would be appealing to end users, but, I certain would encourage improving the scoring as described here. From memory the new engine has tended to be fairly slow/annoyed when I only give it a regex. (I can't tell if that's happening here, as I'm uncertain if it's cheating since you recently searched for it..., and I don't have a particularly good sense of the size of the dart repository, from my perspective, it's a medium size repository -- even though I'm contributing in bite-sized chunks.) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing what you're working on, the spell checker sounds interesting! Our main focus right now is performance and scaling (so we can release the the search to everyone!) so if there are regexes you run into that are slow, definitely let us know. They are slower to evaluate than exact match searches, but a fairly specific regex within a single repo should be pretty quick. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
For this one, we have a special glob syntax you can use: |
Beta Was this translation helpful? Give feedback.
-
|
If it looks like i'm trying to search for that, it'd be nice if GitHub suggested it (it does occasionally make suggestions). |
Beta Was this translation helpful? Give feedback.
-
|
Also a problem when searching issues, whole-word matches work perfectly, substring matches basically never work. |
Beta Was this translation helpful? Give feedback.
Thanks for the feedback @jsoref. I like the idea of indicating exact matches better. We could also use it in our ranking.
For a technical explanation, the reason why the old search finds "roduct" so well is that it tokenizes whole words and some programming-related separators (like
-,_, and case changes such asproductManagerturning intoproduct,manager). The new search supports substring matches, which is why you're getting so many additional results. One way to help is to be more precise in what you're searching for. For example, this regex search for/\s+roduct\s+/finds only the result you were looking for.