lsp: Add HTML Intellisense Support to Templ LSP about templ HOT 16 OPEN

We've talked about HTML intellisense support, but haven't reached consensus on what specific features people are talking about, so it's been hard to understand how/if to proceed.

For example, in #498 (comment), the expectation seems to be that if you put a type attribute on an input should provide a list of stuff, with the assumption seems to be that whatever VS Code does is what we want.

The reason I don't know about the expectations of people, is because people (like me) that don't write static HTML have never seen VS Code's behaviour, so we don't "miss" it. For example, here's what you get in VSCode for JSX (React):

I also tested PHP, which doesn't do anything either. 😁

Assuming we wanted to get all of VS Code's HTML autocomplete behaviour, in https://github.com/microsoft/vscode-extension-samples/blob/main/lsp-embedded-language-service/server/src/languageModes.ts#L46 you can see that VS Code's example embeds the extracted HTML language server (written in JS) into the project. That's how the html1 language is able to define 'areas' of standard HTML.

So, when @joerdav says that we'd have to find more LSPs to run, that's what he means. Templ proxies through to the gopls language server (literally running a gopls process to do so) and re-maps the positions. So users, to get the additional LSP features, would need to have the HTML LSP pre-installed and on their path to get the feature.

To get templ to work in this way we'd have to do the following:

• Make it so it's possible to get templ to render just the HTML tags, text and attributes, and blank everything else out (e.g if statements, switch statements etc.).
• Update the templ parser to store the source code ranges of HTML content, like it does with Go expressions.
• Get the templ LSP to look for the HTML language server at startup, and if it finds it, start it up.
• If autocomplete is triggered in a HTML range, pass just the HTML content over to the HTML LSP and get it to execute the autocomplete, applying the edits on the way back

However, I'd rather not spin up a Node.js process just to run a bit of HTML autocomplete, so if all that people really want is autocomplete on tag names, attribute names, and attribute values, we could probably add that directly to the templ LSP. Essentially, the same process, but instead of starting up the LSP, you work out whether the current cursor position is at the element name, attribute name or attribute value position, and trigger the expected autocomplete.

from templ.

Hi @salihdhaifullah thanks for the proposal.

I just wanted to check if you've tried out the HTML options that are outlined in the docs here: https://templ.guide/commands-and-tools/ide-support

I'm using Neovim and have enabled the HTML LSP on templ files and it works perfectly.

If you're using vscode then the option is to enable emmet completion.

If these are not sufficient then can you please reopen this ticket with details of what you found was lacking?

from templ.

I think they mean something like

It doesn't work in templ

from templ.

Okay, yes I see that emmet does not provide this feature. In Neovim you can just enable the HTML LSP on templ files which works alongside the templ LSP:

I can see that you can modify file associations in vscode, but that means that the templ plugin won't run on the files. I wonder if there is a way to expand the list of filetypes that vscode runs the html LSP on.

from templ.

I've marked the issue as needing some investigation, so we can explore options before taking this as feature for the templ LSP.

from templ.

Unfortunately, I don't think there is a solution for this. Go templates has the exact same problem in vscode, either you edit the file as a gotmpl or as a html file:

https://github.com/golang/vscode-go/wiki/features#go-template-syntax-highlighting

from templ.

Can the templ LSP proxy the HTML LSP?

from templ.

I think @a-h had some thoughts on this. But I can see proxying another LSP as a pain, it's really frustrating that vscode currently doesn't support multiple file associations.

Often the templ LSP has trouble finding gopls to run and proxy, I think having more executables required for templ LSP would damage the ease of install and config. I guess an option would be for proxying the HTML LSP to be an optional feature if the LSP is found, but again balancing multiple LSPs should be the role of the client as Neovim does.

from templ.

Gotcha. I chose templ because I thought it supports this and that (for me) was the "wow" effect. From https://templ.guide/:

Great developer experience: Ships with IDE autocompletion.

I assumed that meant HTML as templ is for HTML.

from templ.

Ah, no that's mostly for the Go side of it, type safety and autocomplete of Go expressions.

from templ.