Finalize smart select api

[jrieken]

• multiple vs single cursor
• define kinds

[jrieken]

current proposal with support for multiple positions: https://github.com/Microsoft/vscode/blob/0507edbcf6c7bb72062fec0e330f59fbffd852a7/src/vs/vscode.proposed.d.ts#L19-L66

[jrieken]

fyi @aeschli @octref - I have removed SelectionRangeKind as didn't yet know what to do with it. I have updated your extensions.

[jrieken]

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;
	}

[jrieken]

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
#69252). cc @mjbvz who brought up this idea before.

[octref]

Re dropping Kind: Do we no longer consider #65308?

I do like with the alternative where we can support prev/next sibling.

[jrieken]

Re dropping Kind: Do we no longer consider #65308?

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.

[jrieken]

fyi @aeschli @octref I have pushed a change that uses the parent pointer approach instead of the 2d array

[matklad]

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.