Allow to filter list by reference kind

[IllusionMH]

It would be great to have an ability to filter found references.
For example:
"Hide imports" that will hide references inside of import statements and direct require assignments.
At this moment each file usually contain 2+ references and first one if always inside of the import statement, but it is rarely place that devs are looking for.
"Hide definition" there is separate commands "Go to/Peek Definition" and when looking for references-usages won't introduce one more.

In combination with #15 (that recalculated according to filters) this will provide proper count of usages.

[jrieken]

/duplicate of #50062

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!

[IllusionMH]

@jrieken I'm not sure that this is duplicate of mentioned issue.
#50062 is about general search/filter while this one is about adding controls for specific filters for references.

In particular references inside of import statements (basically duplicates inside one file where it will be actually used) and definitions (actually #68071 is duplicate of "Hide definition" part of this issue)

UPD.
For example: WebStorm panel for Find Usages

Toggles outlined in read are: Show read access, Show write access, and Show import statements.
If I toggle "Show import statements" then all import statements with reference in question will be filtered out, and I will see only relevant usages.

[IllusionMH]

@jrieken could you please reconsider and re-open this issue because it is not duplicate of #50062?

[jrieken]

Yes, this isn't a dupe but TBH this is far out of scope because the API doesn't define any semantics on references. Eg the editor doesn't know anything about references, they are just pointers to some line of source. The proposed API for call hierarchies (#70231) will have this knowledge and while the first UX is peek based, there will likely be a viewlet based UX too.

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[IllusionMH]

Thank you for explanation.
Just to clarify - if #70231 won't help with expected workflow I need to submit Language Service API proposal to enable more info about reference kind first?

[jrieken]

need to submit Language Service API proposal to enable

Yeah, that would be helpful. Something that enhances this API first:

vscode/src/vs/vscode.d.ts

Lines 2718 to 2731 in 4c5705f

	export interface ReferenceProvider {
	/**
	* Provide a set of project-wide references for the given position and document.
	*
	* @param document The document in which the command was invoked.
	* @param position The position at which the command was invoked.
	* @param token A cancellation token.
	*
	* @return An array of locations or a thenable that resolves to such. The lack of a result can be
	* signaled by returning `undefined`, `null`, or an empty array.
	*/
	provideReferences(document: TextDocument, position: Position, context: ReferenceContext, token: CancellationToken): ProviderResult<Location[]>;
	}

. E.g instead of returning a Location[] allow to return something comparable to DocumentSymbol. Once we have it in VS Code, we follow up with LSP. It also needs a reasonable default, e.g. all Location-only references are of some default kind and then the UIs can follow...

This a long shot, but don't get me wrong. I do like this feature but it will take a while till we are there

[IllusionMH]

@jrieken understood. Thank you again!