Skip to content

Support for embedded languages (bash) #273

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

Open
reteps opened this issue Apr 16, 2025 · 7 comments
Open

Support for embedded languages (bash) #273

reteps opened this issue Apr 16, 2025 · 7 comments

Comments

@reteps
Copy link

reteps commented Apr 16, 2025

Hi there,
Thanks for all your efforts maintaining this project. I am filing essentially a duplicate of microsoft/vscode-docker#4183, as this would be an approach for doing this on the Language Server side, not on the client side.

It is my understanding that is is the burden of the language server to support embedded languages. I would love to see integration with https://github.com/bash-lsp/bash-language-server. I was looking at how one would implement this, and the docs suggest you can do this with request forwarding, or a language service. The language service approach, when I looked at the sample implementation, would be easier to implement and doesn't rely on VSCode-specific features.

@rcjsuen
Copy link
Owner

rcjsuen commented Apr 16, 2025

It is my understanding that is is the burden of the language server to support embedded languages. I would love to see integration with https://github.com/bash-lsp/bash-language-server.

When you say integration what are you referring to? Is your feature request specific to getting syntax highlighting to work?

@reteps
Copy link
Author

reteps commented Apr 16, 2025

Yeah, that would be the main item. It looks like you can pass through completion commands as well, but that is just bonus stuff that would take extra effort to implement.

@rcjsuen
Copy link
Owner

rcjsuen commented Apr 16, 2025

Yeah, that would be the main item.

Thank you for confirming.

The aforementioned bash-lsp/bash-language-server does not support the textDocument/semanticTokens/* LSP requests. Even if I forwarded the requests I would either get an error or an empty response. Does that make sense?

@reteps
Copy link
Author

reteps commented Apr 16, 2025

Yeah, that would be the main item.

Thank you for confirming.

The aforementioned bash-lsp/bash-language-server does not support the textDocument/semanticTokens/* LSP requests. Even if I forwarded the requests I would either get an error or an empty response. Does that make sense?

That makes sense, sorry I didn't realize that their language server doesn't support that. I'm not sure how to support my feature request then 😓

@reteps
Copy link
Author

reteps commented Apr 16, 2025

@rcjsuen Do you think that this is a feature that should happen on the client then? If so, feel free to close.

@reteps
Copy link
Author

reteps commented Apr 16, 2025

I filed a complaint about this particular design point here: microsoft/vscode-discussions#2656. I'm hoping they suggest a workaround.

@rcjsuen
Copy link
Owner

rcjsuen commented Apr 25, 2025

Do you think that this is a feature that should happen on the client then?

There are many different ways to implement this but I do feel it should be solved by the client. Editors are known to provide syntax highlighting for a wide variety of file types whereas the expectation is just not there for language servers. Having the solution be on the client means all servers can reuse the solution more easily instead of multiple servers having to do the same thing and bundle TextMate grammars for every obscure programming language in existence.

We all recognize that having JavaScript in an HTML file is a totally valid use case but providing accurate syntax highlighting for a JavaScript file is a very difficult problem. Given the choice, I would much rather the developers of an HTML language server work on ensuring editing HTML files feels good than trying to invest time into creating a proper AST and syntax highlighter for JavaScript.

If so, feel free to close.

I will keep this open to track the interest around this request. Closing it also means someone might miss it and open the same issue in the future so I might as well just leave it open I think.

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

No branches or pull requests

2 participants