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

fix: Added support for non-standard member token type reported by the TypeScript language server for static methods #692

Closed

Conversation

SCWells72
Copy link
Contributor

This is probably best demonstrated visually. Here's the syntax highlighting without this fix:

image

and here it is with this fix:

image

Note the lack of highlighting for the declaration and usage of static method demo in the first image and the proper highlighting of both in the second image.

…g syntax-highlighted properly. After digging in, it's because they're being reported as non-standard token type "member" instead of "method". This addresses that omission and also creates a more formal way to add non-standard token types.
@SCWells72 SCWells72 changed the title fix: Added support for non-standard "member" token type reported by the TypeScript language server for static methods fix: Added support for non-standard member token type reported by the TypeScript language server for static methods Dec 12, 2024
@angelozerr
Copy link
Contributor

@SCWells72 I understand that the result is very nice, but I would like to really avoid hard code custom token for each language server.

My idea for user defined language server is to have

@angelozerr
Copy link
Contributor

I see that you rebase your PR but as I have tried to explain, I would like to have a more generic support to do that like vscode provides.

Hope you will understand.

@SCWells72
Copy link
Contributor Author

I see that you rebase your PR but as I have tried to explain, I would like to have a more generic support to do that like vscode provides.

Hope you will understand.

Oh, I'm just rebasing all open branches to keep things fresh for when I return to them. I'm not actively working on these right now. I'll change this to a draft PR to prevent any further confusion.

@SCWells72 SCWells72 marked this pull request as draft December 19, 2024 16:30
@SCWells72
Copy link
Contributor Author

Closing this as the simple approach here has been rejected and the more extensive proposed alternative is probably out-of-scope for me anytime soon.

@SCWells72 SCWells72 closed this Jan 6, 2025
@angelozerr
Copy link
Contributor

I am sorry @SCWells72 but I hope you understand my point of view. My fear is that each ls will want to add their own custom tokens

@SCWells72
Copy link
Contributor Author

I am sorry @SCWells72 but I hope you understand my point of view. My fear is that each ls will want to add their own custom tokens

No, I understand. However, if you truly want to be strict about that stance, then the current special handling for label needs to be changed as well as it already violates that concept. I made the changes that I made for those PR based on the existing precedent around label.

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

Successfully merging this pull request may close these issues.

2 participants