colin353

Colin here (I'm the "named employee"). I don't mind being called out, FWIW. I'm proud of what we built.

We would definitely have implemented sorting by recency if it was trivial to implement. But as I said before, our data shows that it is infrequently used, and to scale our search index, we designed it in a way that makes this kind of sorting tricky.

Sometimes to ship products like this, tradeoffs have to be made, and I continue to think we made the right one. Nevertheless, it's good for me and the team to hear feedback like this so we can continue to improve the product.

Hmm, you can construct a regular expression, something like:

``` lang:tsx /<Button[^\\].* color="red"/ ```

Example:

https://github.com/search?q=lang%3Atsx+%2F%3CButton%5B%5E%5C...

Ah, you need to log in to get access to the new code search!

Yes, we're working on bringing it to GitHub enterprise right now.

Great point. Yes, we initially focused on zero-config approximate code navigation. But we do intend to support build-based code navigation in the future, since the approximate code navigation experience can be pretty poor for some languages (e.g. C/C++).

I'm Colin from GitHub's code search team, happy to answer any questions.

For more info on how we built this, you can check out our technical blog post from a few months ago https://github.blog/2023-02-06-the-technology-behind-githubs...

We have not done this yet, but we do intend to.

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.

Appreciate the feedback.

> static view of the core

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.

I'm guessing you are in our Code Search Technology Preview (which was at cs.github.com), which gives you access to this new UI as well.

By the way, feel free to opt out if you hate the new UI - it's super easy to opt out from the code view page, or from the feature preview menu.

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)

Not the case, the mobile app is great, but we know developers use mobile web. It matters to us. Will definitely improve it

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.

I'm one of the engineers at GitHub that built this - happy to answer questions (or fast-track your access into the preview!)

Hey, I'm on the GitHub code search team. We've had a ton of people join the waitlist, sorry it's taking so long to get through everyone! We're hoping to get most people access early in the new year. Stay tuned!

The new search does find filenames! :D

Might also be worth checking out the syntax guide: https://cs.github.com/about/syntax#symbol

GitHub Code Search developer here - try creating a custom scope to filter out that stuff! Click on the scopes dropdown and scroll to the bottom. You can filter out HTML by using a query like:

NOT language:html

We are looking into open sourcing some libraries that we've developed for search. And we're going to write a blog post with way more technical details soon!

GitHub Code Search developer here:

> would love to see this in a UI if it's possible

We do have code navigation via the UI, so in a way it's possible!

> ability to save searches I do frequently

Absolutely! This is possible using "custom scopes". If you're in the technology preview, click on the scope dropdown, scroll to the bottom, and choose "custom scopes". You can make a custom scope to search a set of respositories, a particular language, within a directory, or any combination with boolean operators!

Another GitHub Code Search developer here - to add more to this, we rank all the search results, and try to bring the most relevant results to the top. Ideally, if you have 10 pages of results, you shouldn't have to leave page 1 to find what you're looking for :D

Couldn't agree more - that's why we built it! Please give the new search a shot, I think you'll like it :D

Hey! That was me in the video.

Not ashamed to be a Rust evangelist! The reason I mentioned Rust is because we spent a lot of time making the experience really fast - which is super important for a product like this. I really think getting the performance we have would have been enormously more difficult in any other language.