Skip to content
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

Clarify the query format/syntax for WorkspaceSymbolParams #1674

Closed
rhdunn opened this issue Feb 16, 2023 · 3 comments · Fixed by #1977
Closed

Clarify the query format/syntax for WorkspaceSymbolParams #1674

rhdunn opened this issue Feb 16, 2023 · 3 comments · Fixed by #1977

Comments

@rhdunn
Copy link

rhdunn commented Feb 16, 2023

In WorkspaceSymbolParams, the query parameter states:

	/**
	 * A query string to filter symbols by. Clients may send an empty
	 * string here to request all symbols.
	 */
	query: string;

It is unclear what syntax the query string has, and how a language server is supposed to process that query when matching symbols.

  1. Is it a simple regex-style or grep-style pattern? Is it more complex (e.g. SQL-like or XPath/XQuery like)?
  2. Does this allow class to property/function/variable patterns (e.g. String.replace*)?
  3. Does this allow full/partial package patterns?
  4. Does this allow expanded QName (for XML, XSLT, XQuery, XMLSchema) patterns in Q{namespace}local-name notation or similar?
  5. etc.
@puremourning
Copy link

It's arbitrary, whatever the server implemented. In practice it might be a subsequence match or a prefix match. From client and/or protocol perspective it's just a string.

@rhdunn
Copy link
Author

rhdunn commented Feb 16, 2023

This is a string the client passes to the server:

The workspace symbol request is sent from the client to the server to list project-wide symbols matching the query string.

This means that the language server needs to know how to handle that query string when matching symbols.

At the very least, it should be required for the client to document the query string format. -- Ideally, this should be described in the client capabilities.

The protocol is supposed to be designed to make it easier for any client and language server to be implemented. Here, the language server needs to know the client, what query strings it supports, and switch behaviour on that. -- This is because symbols can be different depending on the regex/query syntax used. Having the format in the protocol request (like is done with things like the regex and markdown formats) would at least make it easier to implement the logic for.

@dbaeumer
Copy link
Member

dbaeumer commented Feb 20, 2023

I agree that this needs to be improved but I am not sure yet how :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants