-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finalize smart select api #67872
Comments
current proposal with support for multiple positions: https://github.com/Microsoft/vscode/blob/0507edbcf6c7bb72062fec0e330f59fbffd852a7/src/vs/vscode.proposed.d.ts#L19-L66 |
The lastest proposal is: export class SelectionRange {
range: Range;
constructor(range: Range);
}
export interface SelectionRangeProvider {
/**
* Provide selection ranges for the given positions. Selection ranges should be computed individually and
* independend for each postion. The editor will merge and deduplicate ranges but providers must return sequences
* of ranges (per position) where a range must [contain](#Range.contains) and subsequent ranges.
*
* todo@joh
*/
provideSelectionRanges(document: TextDocument, positions: Position[], token: CancellationToken): ProviderResult<SelectionRange[][]>;
}
export namespace languages {
export function registerSelectionRangeProvider(selector: DocumentSelector, provider: SelectionRangeProvider): Disposable;
} |
An alternative, and something that would allow us to have sibling navigation, would be export class SelectionRange {
range: Range;
parent?: SelectionRange;
constructor(range: Range);
} So, that the result is the selection range at the request position pointing upwards/outwards to its containing range. That would leave the door open to potentially add sibling pointers so that you can implements something like "go to next argument" or "go to previous field/method" (see |
Re dropping I do like with the alternative where we can support prev/next sibling. |
We still do but we couldn't come with a reasonable list of kinds. Instead of holding back the API longer we should roll out things in stages. |
LGTM! Though I'd expect that, rather than overloading extend selection for navigation by adding "next/prev" pointers, we should just add a dedicated API for that. |
The text was updated successfully, but these errors were encountered: