Skip to content
This repository was archived by the owner on Mar 18, 2024. It is now read-only.

Conversation

@sqs
Copy link
Member

@sqs sqs commented Dec 5, 2018

  • Add a panel action "Show/hide fuzzy matches" to references/definitions panel
  • Default to using symbols locally
  • Add an action to switch between using symbols locally
  • Coexist with precise code intelligence better
  • Only use old toggle action (that disables all langserver/* extensions) on pre-3.0 versions of Sourcegraph

These improvements are intended to make it possible to enable basic code intel for all users on Sourcegraph.com.

fixes https://github.com/sourcegraph/sourcegraph/issues/1175

- Add a panel action "Show/hide fuzzy matches" to references/definitions panel
- Default to using symbols locally
- Add an action to switch between using symbols locally
- Coexist with precise code intelligence better
- Only use old toggle action (that disables all `langserver/*` extensions) on pre-3.0 versions of Sourcegraph

These improvements are intended to make it possible to enable basic code intel for all users on Sourcegraph.com.
Copy link
Contributor

@lguychard lguychard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

function observableOrPromiseCompat<T>(
result: Observable<T> | Promise<T>
): sourcegraph.ProviderResult<T> {
// HACK: Earlier extension API versions did not support providers returning observables. We can detect whether
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should plan to handle the issue of extension API breakage differently - IMO there should be no backwards compatibility handling in extension code, it should be handled at the registry/extension host level.

eg.:

  • If the user has activated the Sourcegraph extension E, which is only compatible with extension API vN, and his browser extension packages extension API vN+1, he receives a notification that "Incompatible extension E could not be activated"
  • If the user's browser extension packages extension API vN, the extension registry will provide the latest version of E that was compatible with extension API vN, even if the very latest version of E on the registry was coded against vN+1

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

basic-code-intel method of disabling lang extensions needs improvement

3 participants