New Code Search and Code View (Beta)

[thispaul]

Update 2023-02-23: Please report all new feedback on this discussion.

Thanks for trying GitHub’s new code search and code view - the most powerful way to search and navigate the world’s code. Our team is excited to share this feature with you today in beta.
We are dedicated to making GitHub the best code navigation experience on the web. If you encounter any issues or have suggestions on how we can improve the experience, please share below. We will review all feedback!

To get access, please sign up for the beta.

[samueldr]

The fuzzy-finder (t) being limited to a tiny column is a definite regression.

[edhgoose]

I echo this feedback as well - I loved the former t implementation. It feels slower too.

[SuperSandro2000]

I am also not sure if it is just me or did the File finder results got worse way harder to navigate?
I know they where not always great in the past but with the recent UI changes I more often than not need to search harder to find what I actually need.

See the following screenshot:
The first line is the only matching one. All other results are fuzzy finder garbage and don't even match two consecutive letters.

Apparently this was the case in the past, too but there the results where a lot denser, so it didn't bother me as much. The new UI is taking double the space for each result and past the first in this example, they are all garbage.

[SuperSandro2000]

The current layout supports left-pane resizing.

which is always the same whether the bar is focused or not. So when you resize it, then the normal navigation gets a bit weird and is really right aligned and smashed into the right edge of my screen.

[0xdevalias]

I would also like to be able to paste a full file path, with optional line number into the cmd+k dialog, and have it also suggest opening that file, at that line number.

I would like to be able to use the t (Jump to file) shortcut, and give it a full path, optionally also with a line number, such as foo/bar/baz/index.js:123 and have it jump to the correct file and line.

I believe it used to be possible to use this with the file path (without line number), but now even that seems to fail using the new code search/etc beta.

Originally posted by @0xdevalias in https://github.com/orgs/community/discussions/9671#discussioncomment-4385739

Originally posted by @0xdevalias in https://github.com/orgs/community/discussions/39163#discussioncomment-4385754

[furry72]

is ugly, the new code search, i will hope disable that weird search

[samueldr]

Navigating away/to/through the root of the directory in and out of the new code view feels disjointed, as you're popping in and out of the new view.

I understand that there is content on the root page that is not replicated elsewhere, but I think this mean it's time to review and redesign how the root page of the repository works. Considering this, I believe the root page of the repository should be configurable, and allow choosing between e.g. README view, File browser view, issues or discussions. This would help project management when projects have e.g. a repository dedicated to issues, or to discussions.

[thispaul]

Thank you for trying the new code view! We plan to redesign the repo overview (root) page soon, and will definitely take your feedback into consideration!

[odiferousmint]

Personally if I could, I would probably set to something like whatever "Timeline" is in Trac as the root page. Many people seem to use GitHub as their project management software, so why not have such a page? I think the closest to it on GitHub is "Insights". Correct me if I am wrong though.

[samueldr]

I see from this post, and the documentation, that it's supposed to be limited access during the beta, and behind a wait list.

Unless I registered a long while ago (I don't remember doing this), AFAICT for me this got activated without warning today.

Are there special considerations for some group of users that participated in a previous beta, that would mean it gets enabled for them too?

[edoderg]

😭

[skylar-anderson]

@samueldr and @alexanderankin - thank you both for providing feedback about the navigation experience.

really clunky to navigate (maybe just learning a new system).

If you prefer, you can navigate GitHub in the familiar way by closing the tree sidebar using this button here:

If that doesn't help, I'd love to learn what specifically feels clunky. We're committed to getting this right and every detail helps. Thanks!

[skylar-anderson]

@alexanderankin - Wow, this is super helpful feedback. I hear you and appreciate the time you took to articulate your concerns with these changes. We will take your feedback to heart and continue to iterate until we get this right.

[karenl1]

it's too complicated i just want to look at my text file

[edoderg]

🐐🐐

[skylar-anderson]

Thanks for sharing @karenl1 - Is there something specific we could improve to make it feel less complicated?

[karenl1]

keep it the same

[Oniii69]

How can i switch back to normal old classic mode ???????
This new update is just grossssss

[depascalis]

I like everything I've tried this far, especially the tree-view panel, some pointers though.

1. On the search page, I can´t figure out how to get back to where I was before doing the search (most often a repository). If I do a search in a repository, it doesn't feel like I'm in that repository anymore.
2. I'd like easy access to the search syntax from the search input, like a modal or something. The modal should include all available operators and tags etc. with a short description, more complex examples can reside in the documentation. I don't like to visit the docs page every time I need to do a more complicated query.

Nice work so far ❤

[Ldoppea]

1. On the search page, I can´t figure out how to get back to where I was before doing the search (most often a repository). If I do a search in a repository, it doesn't feel like I'm in that repository anymore

Hi, same issue here, it would be great to have an easy way to:

• start a search from a repository
• navigate the results
• easily go back to the origin page when the search is complete (can be the repo root, a code page from this repo etc)

[depascalis]

@Ldoppea your first point is already possible, just do the search from the repository and the repo:some-repository will already be filled in.

[Ldoppea]

@depascalis sorry, maybe it was not very clear. I was just describing a scenario where being able to go back to the origin page would be useful. My request is about having the third bullet point to be possible (the one in bold). In fact this is the same request than yours but with my own words 😄

[deric4]

Is it possible to have Code View activated at the project "root" level? It seems to only get activated once I've clicked into a file or directory.

Also, it would be amazing if the file size was reported as well. The amount of time I spend checking __init__.py python files to see if they're empty or not when exploring a new python project.... 😅

main page: https://github.com/deric4/github-action-runner-reference

nested dir: https://github.com/deric4/github-action-runner-reference/tree/main/.github/workflows

[look]

@radekg You can turn it off in the Feature previews menu of your settings.

[radekg]

@radekg You can turn it off in the Feature previews menu of your settings.

@look Yes, I know. But one day it won’t be a feature preview and I still don’t want it. I have my editor for a tree view. I can press the dot if I want a tree view. I want a list of files and nothing else.

[nguyenvulong]

This is all I wanted to make Code View replace Octotree, for a simpler chrome extension list 🍰

[PrayagS]

Octotree is still miles better. GitHub's implementation feels slow and sluggish (especially the fact that it has to load the files when I expand a directory). Octotree loads the whole file tree at the start.

[PrayagS]

Octotree is still miles better. GitHub's implementation feels slow and sluggish (especially the fact that it has to load the files when I expand a directory). Octotree loads the whole file tree at the start.

[cysp]

This new search functionality and UI is incredible, huge congratulations and thank you for shipping this!

I've already made use of the ability to find results in a commonly-named directory across all repositories in my org!
And – while I haven't used it in anger yet – the tree view of files in a repository is brilliant.

Thank you!

[davekenn]

Fantastic! Thanks for using the preview and we hope it continues to delight!

[cysp]

I've now had occasion to use the code browser, the symbol browser, the integration of that search functionality to find the definition of a symbol, then searching for usage, and then used the available path list to quickly apply path filters.

And every time I used the next part of that flow, the ui elements shown were exactly the functionality I was after and they did exactly the thing I wanted.
Very impressed!

[yamatsum]

File Tree View file icons are all the same, so I want you to change it by extension.
I want you to create an icon for each language with octicons

ref:
https://github.com/yamatsum/nonicons

[skylar-anderson]

Thanks for sharing @yamatsum! This is something the team is discussing.

[yamatsum]

@skylar-anderson
Thank you for creating such a wonderfully designed product!
If possible, I would be happy if the Symbols part was also iconized!

I think it would be better to at least be able to see the list of symbol abbreviations and what each one means.
e.g. intf = interface

[skylar-anderson]

Thank you for your kind words :)

I think it would be better to at least be able to see the list of symbol abbreviations and what each one means.
e.g. intf = interface

This is an interesting idea! We do show the expanded symbol type when you click into a symbol, but nonetheless I can see how this list of abbreviations is confusing. Thanks for sharing

[bburky]

I also noticed a new per-file search UI appears when I press command-F now. It generally works well and I like it, except it behaves poorly with long lines. If I search for a term that matches at the end of a long line:

• The list of match results only show the beginning of each line and my search term may not appear in the preview snippet at all.
• When selecting a match, the browser window is not scrolled horizontally to move the matched string into view, it only scrolls vertically to the line.

[skylar-anderson]

Great catch and thanks using the new UI and for sharing this feedback. Both of your points are valid will be corrected.

[aevangeline]

Hello! I just wanted to reach out and say that we've launched a new cmd-f feature in the code view beta. We'd be very interested in hearing what feedback you have about it!

[rockwotj]

This is amazing thank ya'll for your work here - one bit of feedback is that the commit message previews could show more at times.

It looks like it's a standard table element - I wonder if using CSS grid (or even just plain flexbox) would give more flexibility to always prioritize giving extra space to the commit message if there is room.

[GlebIrovich]

Thanks for your feedback! We used table as it is more accessible for screen readers, but using screen estate more efficiently is definitely a good point! 🚀

[charlieley]

The UI looks alright, however would I get search results sorted with "recently indexed"? In the previous version, code search results could be sorted with "s=indexed". That option doesn't seem to be working anymore. There doesn't seem to be any way to sort code search results at all. If someone could advise...

EDIT - The UI maybe has a glitch. When doing a code search with "&type=code", there's no options button on the top right hand.

However, if I navigate to repo or commit search, and then come back to code search, there is now a setting button, to toggle "legacy code search", which allows sorting of code search results with recently indexed. Code search is "&type=codelegacy".

However, this has more questions -

1. Is code search sorting via "recently indexed" not going to be present at all in the new code search?
2. This new UI was applied automatically without any warning. Is legacy code search going to be retired without warning going forward?
3. If legacy code search is retired, would any sorting on code search results be there, specifically "recently indexed", since the results are "best match" by default at the moment?
4. Even in legacy code search, the recently indexed time is gone. Is that change going to persist?

[tclem]

Can you say a bit more about why having results sorted by "recently indexed" is important to you?

[charlieley]

I look at recently indexed results, which are generally pieces of code written and committed in recent times (though of course, on occasion, an older piece of code gets indexed by the engine) with certain keywords, to plot trends against evolving technical events centered around those keywords. This cannot be done with repo / commit search and the default "best match" search provides results which may be quite old (in best search, recently indexed could be quite down the search results for some keywords ). Due to this, the recently indexed, and on occasion, least recently indexed sorts are quite important, and I'd appreciate it if they weren't axed. They're there, they generally work well, and if not broken, should be carried through in any search feature iteration which GitHub brings out.

[Hakky54]

I use it so find out who started recently using my libraries and whether I can provide them feedback. If needed I provide them a PR for improving the usage etc. For my use case it is really useful, so I would love to have this sorting option based on recently indexed

[Tedixx]

As a security researcher involved in OSINT monitoring, the "recently indexed" functionality is crucial to identify newly released data in relation to monitored assets. I understand that there is a possibility to sort on a specific time window, but that is a mitigation for a problem that was not present at first.

[MyOneTaps]

And when there are breaking upstream changes, in lieu of much harder to implement domain-specific filters, sort by newest is a fairly high signal proxy for finding code that have taken those breaking changes in account.

[PhilippGrulich]

This feature is vary cool! Is there already a plan of C++ symbol search support?

[look]

We want to add C and C++ symbol search. We had to take it out of the initial release because it wasn't reliable. :-/

[tclem]

If anyone is curious or even interested in contributing to the open source project that powers symbolic language support we're using tree-sitter and tree-sitter-cpp and tree-sitter-c would be the parsers that need some improvement.

[burpheart]

It looks like the new version of the search engine does not support sorting of Code search.
Using search tags also cannot be sorted
"The sort qualifier is not supported when searching code."
Sorting the code by commit time is also a very important feature.
This is especially important when there are a large number of query results.

I also noticed that the word segmentation in search engine has changed significantly.
The current version does not seem to support exact search. Only fuzzy searches are possible.

[look]

@zhao-pf the new code search is now generally available, so we have removed the option to switch back to the old system.

[Avnsx]

please bring back the switch atleast, the new UI is very buggy and not thought through

[zhao-pf]

@look Thanks for your reply.but I can't according to the latest date for sorting the code page, how do I solve

[arkivanov]

I'm missing this feature. This is a regression.

[furry72]

that, that and hate it the new code search

[DominickVale]

It looks good, but honestly, the file tree sidebar is not showing up where I need it the most (root page). The views also feel inconsistent (actually my initial impression was that the layout was broken)

[davekenn]

Thanks for using the preview! We are planning to work on the root repository overview page and bring it into the new design.

[gtsiam]

Love it!

Though there's a visual glitch if you highlight a line (click on the line number) and then click on a symbol (here I clicked on exec_path)

[gtsiam]

Actually the particular glitch I screenshotted above seems to have to do with clicking on the exec_path part of self.exec_path, but there's another glitch having to do with line numbers I was trying to get but failed:

• Highlight monitoring (the latter on the image)
• Click on the line number

[Dowwie]

I don't see a way to sort code search by last indexed. The age of code is important in many of my searches. It seems that the ability to easily see the modified dates and index dates has thus far been an overlooked feature for the new github search.

[aevangeline]

Thanks for raising this! We're actively investigating ways to make search more useful and more options to tune search rankings has come up! We'll try to push towards solutions on this front!

[colinwm]

@Dowwie, can you elaborate on what you need the modified/last indexed date for, and why you'd need to sort by it?

[Dowwie]

I care about the age of source code. Newer code is more likely to use newer patterns and dependencies. For instance, Elixir's Phoenix framework has had breaking changes, and if I wanted to search for an example of something related, I want to see the most recent implementations that presumably were the most recently indexed.

[colinwm]

Interesting, thanks for that info

[btinfo]

Doesn't it (sorting) a basic function of any searching?
No one wants to see codes that updated 3-4 years ago on top of search result.

[damien-johnston]

Not sure what I should do, I added the beta search for the additional search capabilities and now users can't search my public repo.

Tried to disable this beta feature for a bit, but search stops working completely.

It seem like users need to be signed up for the beta version to search the repo in any way?

It also seems I can't roll back and disable the feature to use current production version of search.

Please advise on what I need to do so that search works again without users having to go to the wait list for the beta feature.

repo:
https://github.com/damien-johnston/ict-index

User without the beta feature enabled.

User with feature disabled

Same user as above but with feature enabled

[damien-johnston]

Figured out a work around for ict-index search on GitHub, tested with a GH user that doesn't have the beta search enabled.

Here's how it works.
Login to GitHub with your user.
https://github.com/

Then go to the old search URL. cs is the old code search and it still works!
https://cs.github.com/

Any search you do must start with this term to filter it to the ict index repo.
repo:damien-johnston/ict-index

Here's an example search for the term "fair value gap" and "NWOG"
repo:damien-johnston/ict-index "fair value gap" AND "NWOG"

I like the old UI results better tbh.

[look]

To clarify, cs.github.com is the same search index as the code search beta on github.com. We used it for a Technology Preview before implementing the features in github.com.

[damien-johnston]

Understood, the user I'm testing with has signed up for the beta and I disabled it, to test today. I'd tested last week with this user without signing up for the beta and couldn't get any results from the code search from the repo. Wiki results but no code. More that one user has reported this issue to me.

When I tested the cs subdomain today it was with the same user account as last week, but I'd signed the account up for beta search and it was enabled when I looked today, I disabled the feature for this test using the cs url.

I just tested with a new user that has not signed up for beta search yet.

The results from the cs url and the repo like the old search, I get the search results from the repo with this new user where the last tests (pre beta signup) yielded no results on the repo search.

hth

[davekenn]

Sorry for the delayed response @damien-johnston! The underlying issue was with the elastic search version of code search, which had some faults that week you started seeing issues. My team kicked off a reindexing of your repository and I have verified that the legacy search is working now. I do want to call-out that was unrelated to trying out the blackbird based search in the beta, so please continue using the beta and providing your feedback!

[damien-johnston]

@davekenn, thank you for the update and clarification on what was happening at that time during the rollout and fixing the issues we experienced with the beta search. I've been so busy I must of missed your reply a few weeks ago.

The new syntax and capabilities are a great value add for us, returning relevant results saves a lot of time for our users, there are some UX features that have been removed from matches and results that are valuable.

We've had to use the beta test site to get the full value out of search due to the new UX in prod.

I've detailed what we are experiencing wrt to missing features with new search verses old search in a post here in the discussion. Please have a look and let us know if there is a plan for feature parity.

https://github.com/orgs/community/discussions/38692#discussioncomment-5386113

[DanielHabenicht]

I also have to add that the use of space on some monitors is lacking (especially wide screen or high resolution):

So much unused space and yet I have to scroll

[milemons]

Thanks for reporting this! There is a setting in the ... menu on your screenshot that will allow using the full width of your monitor!

Screen.Recording.2023-02-21.at.8.56.56.AM.mov

[DanielHabenicht]

Thanks for taking the time to even show it as a video!
Unfortunately, the left "Symbols View" still has the scroll bar:

On the bigger screen the paths are cut in a weird way:

[namzo]

[aevangeline]

Thanks for bringing this to our attention! I'll make sure this gets addressed!

[aditya81070]

Are there any plans to integrate code search for the PRs as well? I am using code search for a couple of weeks and code navigation is fire but code navigation at time PR review is still very old. The new file tree works but it gets irresponsive for PRs > 50 files.

[whjvenyl]

The new code search messes up https://github.com/OctoLinker/OctoLinker which I depend heavily on to navigate between files in a repository 🙈 The symbol palette on the right side is quite nice, but for me nowhere near the added functionality of the linker plugin.

[damien-johnston]

The beta UX is much different and harder to use than the old search and even the beta test site.

There are some features that have removed in the new beta search results UI that is being rolled out in prod. Making it much less user friendly for us. The beta test site is being retired without including these features, making valuable search results much harder to find.

e.g. The beta test site and old search UI had more real estate, better graphical color formatting, and most importantly a search matches line number control that allowed users to increment through multiple matches in returned files is missing from the prod UI.

I'm including some screenshots to show the difference between the same search results from beta test and our repo.

The search used for both examples.
repo:newsqlguru/ict-index "SMT" AND "Divergence" AND "Relative" AND "Equal Low"

---

Beta Test, the old UI.

Note the nicely formatted and highlighted matches text.

• Drilling into a matching file, note the nice formatting and the matches control in the upper right. This is key when there are a large number of results that match.

---

This is the same search on the new beta UI from our repo in prod.

Note the plain text without color.

• Drilling into the same file as the above example, note the color format but missing matches control allowing us to review multiple matches in the file, and duplicate results are not highlighted. As users we must now scan or search again to find matches.

---

I hope this can be addressed before the beta site is taken down, as it's a core of search functionality for us.

If there is something I'm doing incorrectly and a way to enable the matches control in a returned file in production please let me know.

[colinwm]

Hey @damien-johnston, thanks for the feedback. Regarding the syntax highlighting in the search results, it's something we intend to fix soon. The highlighting is dropped in your example because the lines are extremely long, and are truncated in an attempt to preserve readability (though admittedly on your wide screen, it's more readable with colors than with truncation!)

Regarding the second issue of retaining match state into the search results page, we do intend to do this soon, but it unfortunately won't be available before we shut down cs.github.com, sorry about that. Glad to hear you enjoyed that feature, because I wrote it. I promise I'll bring it to github.com as soon as I can.

[damien-johnston]

Hey @colinwm, thank you for getting back to me so quickly and providing an update on search and these features that are valuable to our users.

The match state control in the search results page you wrote is very useful to the users that search our repo. It will be missed until it is rolled out again.

The new version of search is a huge improvement over the prior version from a search query construction perspective, providing better more accurate and relevant results, which saves a lot of time scanning.

Highlighting and format helps draw the eye to the line and match quickly, when in one of the the result files and there are multiple matches, it becomes very important to highlight each of them so we don't have to scan the entire file or search each term with a "find" search on the page or something clunky like that.

A count of matches per file on the initial results page helps to refine the results quickly in many cases, especially when there are many files returned with matches. It allows us to focus on the files with the most content that match what we are looking for. This is another data point that I hope can be brought to parity with the prior version.

Please keep me in the loop or post when you guys are ready to roll out the match state feature or other improvements. I'd be happy to use it in beta or test when ready.

[AliAryanTech]

My humble request please allow us to use old code interface - See this

[gordonlu310]

I agree. Is there a way to switch back to the old interface? @thispaul

[Avnsx]

How do I switch back to old interface, it was possible for some time, did they just remove that option too now or what

[yunginnanet]

P L E A S E

[AliAryanTech]

I apologize, but @thispaul can you give review?

[furry72]

please

[Avnsx]

also the new code editing layout is also very bad. when you click preview then compare what you actually changed in previous commits to the new commit you're about to publish and want to write the commit change history thing, now you first need to click commit which then opens up another pop up, which is insanely unhandy, as then you can't scroll around on the preview comparison view anymore or atleast it's very darkened up. and yes i know you could now just use vs code etc to publish the commits, but what is the point of destroying such a handy in-browser feature

[furry72]

Talking Github, and say that remove this bad layout code search

[ghost]

OK it seems you can somewhat disable this now. click More file actions, then under View options disable Open symbols on click. Also, to disable the cursor, you can use this filter with uBlock Origin:

github.com##.code-navigation-cursor

or for another method, everything is disabled if you are logged out.

[furry72]

When go to Code when login, the new UI is back

[tonglil]

There is something going on with code rendering that makes the text fuzzy when the page scrolls.
It's the most subtle but areas of text on the top and bottom of the window are vertically blurred after scrolling until you mouse over it or scroll in the opposite direction.

Looking at this on

Hardware Overview:

  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro18,2
  Model Number:	Z14W0010BLL/A
  Chip:	Apple M1 Max
  Total Number of Cores:	10 (8 performance and 2 efficiency)
  Memory:	64 GB

System Software Overview:

  System Version:	macOS 13.4.1 (c) (22F770820d)

Firefox:

116.0.2 (64-bit)