-
Notifications
You must be signed in to change notification settings - Fork 29.5k
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
Document guidelines to enable language features for embedded languages #47288
Comments
@popcorner PHP files are actually not adhering to HTML syntax:
(snippet from here |
The problem is, how can I say I'm the master without maintaining a fork and rule them to only work in specific parts of a file? Why can't the language servers I want to control say what they are able to handle, so I do not need to worry about it and the end-user can install any extension they like, so I do not need to upload an extension douzens of megabytes big to support really any language? |
You don't need to maintain a fork. You can forward the requests. But your Smarty server needs to transform the document to valid HTML and then ask the HTML server for the result on this document. That's approach number 2. |
I'm looking forward to an example code. ;) And somehow you didn't answer on my second question. How can I know, when I want the users to install extensions without any more config to know why parts can be handled by which server? |
I don't understand your last question. Can you rephrase? |
You can use Smarty for everything, it's not dedicated to html, css, js, java, xml, json... So in the current version I need to detect which language it actually is, but that's the downside, because I want the language servers that the user installed to give me examples of what they are able to handle, so I do not need to worry about, and it's completly modular(so I would not need to detect whether it's PHP or Smarty code).
That would be sooo easy and soo extensible. I hope you understand why that concept would be so awesome and the next step. |
@aeschli the html language server went with option 2 first for embedded languages then changed to option 1 later. Were there other advantages, in addition to those listed above, that prompted the change in direction? @jens1o In that situation one solution could be to provide a config setting so the user can declare what the embedded language is. Then your extension can create virtual documents with the appropriate language id and forward them on. |
I want to make it as simply as possible, prompting the user for this to declare is very likely to include an error or missing an exception. |
@bmewburn The main reason was really to be able to control the user experience. For example in the case of JavaScript embedded in HTML, we want to preconfigure the JavaScript language server with the dom definition files. |
Can you clarify "samples" with examples? Currently if you want to get HTML completions in your extension, all you need to do in your extensions are three things:
If you are writing a language server that could handle embedded language X, things such as "getting range and content of embedded regions" (for 1 and 2) should be the language server parser's responsibility. |
I mostly mean regular expressions, so to keep it as universal as possible. I'm not an exact regex expert, but for detecting PHP sections this could be used:
These (more complex) patterns would be given to vscode and can be polled by each language server. Then, a simple pattern matching is used to determine the matching language server where the request will be passed to by the The problem is: Languages do not need to have some kind of start- and endpoint(e.g. javascript). Thus, a fallback language determined by the |
@jens1o There would be many problems with that approach, just off the top of my head:
|
So, I do not have a better solution, yet. Do you have some better ideas?
That's supposed to be like this, because it's the job of the master language server.
Perhaps we can include sub-languages while only checking whether a specific keystroke is in of the range.
Would that decrease the cost and pressure of vscode? |
@jens1o You are also assuming that language servers always want to give full control of sub-regions to other language servers. For example, in Vue Language Server it suggest If you want to find a generic solution that should be put in VS Code (@aeschli thinks it's impossible and so do I), try to at least find a solution that could handle at least both PHP and Vue. The solution shouldn't make VS Code slow or make any LS limited in its language capabilities. If you do find such a solution I'm in all ears, and the issue for that is #1751. Up till then, this issue's scope is for providing documentation, guideline and possibly starter template for making language servers that support embedded languages. |
@jens1o I've just reworked on the Language Server Guide. This is something I have in mind. I can't promise anything, but probably sometime later this year. |
Okay, I'm working on implementing this. I've got one problem though. When I pass vscode the request, it apparently passes it back to me, then I pass it to vscode... Infinite Loop. How can I get around this and declare the specific code-part as another language, so (in my example) the Emmet provider rules it all? |
@jens1o Can you create a separate request? Thanks! |
@aeschli Where? Here? At the community slack? |
Just a new GitHub issue. |
@octref I see that you closed this issue. Is there a link to the created guideline? I tried following some of the referenced issues, but was unable to find a related guide. |
In VSCode each file is associated with a language. Language supports such as code completion, hovers, are contributed to that language. This is ideally through a language server.
When a language allows to embedded snippets of an other language (e.g. CSS in HTML or HTML in PHP) there are various techniques that a language server can use:
The first approach has the following advantages
In either case the embedded content needs to be escaped according to the owner language. E.g
>
needs to be>
.The text was updated successfully, but these errors were encountered: