Yes, we never fully trust the search index so before anything is displayed to the user there are a number of final checks performed to make sure you're actually allowed to see that content.

Another fun example is that your SSO session might have expired. While you technically have access to view the result, we can't show it until you go through the refresh dance to get another valid token.

@chrisseaton you are correct, the JSON file is generated. The handwritten parts are:

- https://github.com/tree-sitter/tree-sitter-ruby/blob/32cd5a0... - https://github.com/tree-sitter/tree-sitter-ruby/blob/32cd5a0...

So about 2k loc.

The trickiest (and most verbose) parts of the external scanner have to do with heredocs and the various ways to declare literals (strings, symbols, regexes, etc).

So what's cool is that while we don't handle that during parsing, you can use another set of tree-sitter features to do tree queries to achieve this. Here's the query for detecting Ruby locals: https://github.com/tree-sitter/tree-sitter-ruby/blob/32cd5a0... and here's some better documentation for how the query language works: https://tree-sitter.github.io/tree-sitter/syntax-highlightin....

Hey thanks! I'm one of the primary developers of this grammar along with @maxbrunsfeld. It was the driving force for supporting an external scanner and while there are still some Ruby edges cases, I'm pretty happy with how it came out. I will say we spent a lot of time on this and I read both the bison Ruby grammar and whitequark's ruby parser (which is excellent) in great detail to understand how to deal with certain parts of the language.

One thing I love about tree-sitter is how both the grammar and the resulting ASTs are so readable. I can come back to this project after months of not contributing and pick up right where I left off.

A lot of inspiration did come from the git-media project which goes back to at least 2009: https://github.com/alebedev/git-media/commit/705ea59bd98a3d1...

git-bigstore is awesome too though!

There are some minor differences for integrating with GitHub Enterprise, but just about all the documentation at http://developer.github.com/ applies to both products. While the GitHub.com API is accessed at api.github.com, the API for a GitHub Enterprise install is accessed at yourdomain.com/api/v3/. Definitely shoot us an email if you've got more questions or run into problems: support@github.com.

A personal website is just fine. We're mostly interested in a link to something that you are building or plan to build that integrates with GitHub.

We currently have no plans to make it harder to use the API if you aren't part of the program. If you are a business that relies on our API, we want to have a better relationship with you because there is a good chance we share a customer base.

You really should make that clearer. We have a GH Ent. account, and I was curious about what this might offer me when building tooling that we use internally. Nothing on that page gives any real clue. And the link on the Registration page redirects you back to the same page you were just on moments ago. Or at least make a developer friendly page for those that don't grok marketing text.

And you'd do what with our customers? Or you'd give us customers? You're big, we're small…how is this not going to be a Twitter API-ocalpyse situation?

Respectfully yours, Someone who was in the shit

I'm still not clear what a developer license to build and test against GHE is. "Take on the enterprise" links to a support form.

GitHub Enterprise is the on-premise version of GitHub.com that you can buy to run on your own servers. If you are in the developer program and building a product that integrates with GitHub Enterprise, we will give you free licenses for dev/test purposes.

OK I see, thanks. That does sound useful.

Send us an email at support@github.com if you are having trouble and we'd love to sort it out.

Did you contact support@github? We definitely want to know about that.