4 ms·

> I think Sourcegraph is trying here but that still does not seem to use some kind of accurate and structured information like you have in the code, it still se

by sqs 8y ago

> I think Sourcegraph is trying here but that still does not seem to use some kind of accurate and structured information like you have in the code, it still seems not use build rules Sourcegraph does use language servers (same as your editor would use) to get precise definitions and references. For example ("find references" on some open-source code): Go: https://sourcegraph.com/github.com/theupdateframework/notary/-/blob/server/storage/tuf_store.go#L37:74&tab=references https://sourcegraph.com/github.com/theupdateframework/notary... TypeScript: https://sourcegraph.com/github.com/ReactiveX/rxjs/-/blob/src/internal/Observable.ts#L19:39&tab=references https://sourcegraph.com/github.com/ReactiveX/rxjs/-/blob/src... It understands many build tools, but not all. Go, JavaScript, TypeScript, Java, Python, and PHP support is all pretty solid. If you use the most common build tools for your language, it usually works well. It degrades un-gracefully if you use custom build tools or scripts, unfortunately, but we're working on making it support more build tools and customization. Sourcegraph development is open source; if you notice any problems, let us know in the issue tracker at https://github.com/sourcegraph/sourcegraph https://github.com/sourcegraph/sourcegraph.

Ayyar 8y ago
Thank you for the reply, appreciate you reading the comments so thoroughly. My top piece of feedback is considering some form of a strict mode, where your vision is not best effort support support for some legacy tool for a language, but fabulously amazing knock your socks off good support for users who take the time to invest in making their build friendly with your search index. It might seem tempting to go after the longest common denominator audience here, but personally I think it's far more valuable to show users how code search can be amazing if they do their part to invest in it, vs. code search being "kind of sort of useful" if you have a fallback. And maybe my Xoogler experiences are showing here, though Bazel / Kythe are in my opinion the perfect vehicles to realize that vision.
- sqs 8y ago
  Very good points, thanks! We will be exposing a lot more configurability and extensibility in Sourcegraph in the next release (3.0-preview, and 3.0 more generally). I will add Kythe support to our roadmap and will think about how we can offer a strict mode soon. (We will need to offer that when Sourcegraph supports "write" functionality like automated refactoring, but it would be great to have it sooner.)

by sqs 8y ago

Ayyar 8y ago

Thank you for the reply, appreciate you reading the comments so thoroughly. My top piece of feedback is considering some form of a strict mode, where your vision is not best effort support support for some legacy tool for a language, but fabulously amazing knock your socks off good support for users who take the time to invest in making their build friendly with your search index. It might seem tempting to go after the longest common denominator audience here, but personally I think it's far more valuable to show users how code search can be amazing if they do their part to invest in it, vs. code search being "kind of sort of useful" if you have a fallback. And maybe my Xoogler experiences are showing here, though Bazel / Kythe are in my opinion the perfect vehicles to realize that vision.

sqs 8y ago
Very good points, thanks! We will be exposing a lot more configurability and extensibility in Sourcegraph in the next release (3.0-preview, and 3.0 more generally). I will add Kythe support to our roadmap and will think about how we can offer a strict mode soon. (We will need to offer that when Sourcegraph supports "write" functionality like automated refactoring, but it would be great to have it sooner.)