Actually, our search engine is so fast that syntax highlighting the search results is often slower than finding them... so if we store the language tokens directly in the index, we'll be able to directly emit syntax highlighted snippets and make it even faster.
It may also enable some interesting search capabilities in the future, like searching within comments or by code structure.
Good question. We still construct ngrams for it, exactly the same way. So for example, we might extract `aaa`, `aaa`, and `aaa`. Or we may extract `aaaa` and `aaaa`, or perhaps `aaaaa`. Then we deduplicate to find the unique ngrams and look them up in the index.
So it's possible that a document containing `aaa` might match our ngram search, but we double check after retrieving them and exclude them from the result set.
Hey saagarjha, thanks for the feedback. It's our goal to make the experience as good as possible, and we're aware of shortcomings with cmd+F and `t`, among other things. We're working on it, and your feedback helps us a lot.
We read all the feedback on the forum here: https://github.com/orgs/community/discussions/38692, so please keep providing it. Videos and screenshots are super helpful too. Thanks for bearing with us as we continue to polish the UX!
Hey everyone, I'm Colin from GitHub's code search team: happy to answer any questions people have about it. Also, you can sign up to get access here: https://github.com/features/code-search
We have fixed it behind a feature flag that isn't yet rolled out. Still experimenting with it. But expect to see that resolved in the next couple weeks
Positive feedback feels nice, but negative is way more useful to making a great product.
We're changing an website that millions of people use every day. Hopefully we mostly have a positive impact. But if we're making it worse, even in a small way, that matters a lot to be aware of.
Not sure what you mean by that, can you elaborate?
FWIW we are working to more tightly integrate code search into the code view.
And absolutely, performance matters a lot to us. Sorry for the slow experience, you're not the only one, particularly outside the US. Only thing I can say is we're working on it.
We're not using server side rendering extensively at GitHub (yet) but are experimenting with it on some React pages. Hoping to make the pages even faster than the previous Rails/ERB pages
GitHub has been investing in React for a while (e.g. see our accessible React design system https://primer.style/react/). Many developers at GitHub have experience with React, which helps. And the tooling is just more mature (IMO)
Yep, aware of these mobile issues and are actively fixing them, will hopefully improve in the next week or so.
And thanks for the feedback. We're in Beta right now exactly so we can get feedback so please don't hesitate to reach out (in-app, via Discussions https://github.com/orgs/community/discussions/categories/cod..., or any other way you can reach us), even if it's something minor
This is just the first step of using React within GitHub.com, so we still use a lot of traditional Rails/ERB, even on the React pages (e.g. for the header/footer).
I'm one of the engineers at GitHub who was behind this new UI, let me know if you have any questions. We chose React for this code search/code view because it has a lot of interactivity, and it has worked well so far.
And we do intend to write a blog post with more details in the coming weeks.
Actually, our search engine is so fast that syntax highlighting the search results is often slower than finding them... so if we store the language tokens directly in the index, we'll be able to directly emit syntax highlighted snippets and make it even faster.
It may also enable some interesting search capabilities in the future, like searching within comments or by code structure.