runem / lit-analyzer

Monorepository for tools that analyze lit-html templates

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Are auto-closing features not working or are they just not implemented?

vdegenne opened this issue · comments

    Are **auto-closing** features not working or are they just not implemented?

I was wishing this update would fix that but it doesn't (even though auto-import works now) or am I just missing something?

By auto-closing Here's an example :
In a string literal, I start to type dis the autocompletion frame pops, then I select display to autocomplete.
It autocompletes the property but then I have to type ":" and ";" manually (which is automatic in vanilla CSS files) :

What I get in an element context (after completion) :

static styles = css`
#header {
  display<caret>
}
`

What I get in an html file (after completion) :

<style>
#header {
  display:<caret>;
}
</style>

And the same goes for HTML literal templates <=> files, as well.

Wouldn't that be easy to implement? If it's just a matter of forwarding an attribute from the IDE settings to the plugin parser.

Originally posted by @vdegenne in #200 (comment)

I am still looking for this, that would be really helpful. If you don't really have time, could you at least please give me some clue as to where to look into the code (as I am totally new to VSCode extension development).
I could try to see what changes would cause this feature to pop (I am sure it's just a matter of tweaking a function to tell VSCode to use auto-closing feature on the template).

That would make this feature a little more lit than it already is.

Thanks

@runem @43081j

There are these interesting functions on the CompletionItem class.

image

insertText, commitCharacters, textEdit , ....

The insertText can be a SnippetString .

But I didn't find in the code the location where you provide new items to the CompletionItemProvider.
Can you guys help me?

im not sure this will be an easy one to solve.

im gonna take a wild guess that this option in the CSS language service is what decides if that happens or not:

https://github.com/microsoft/vscode-css-languageservice/blob/84bb8984341aaff3529b9270d017ae92e791a398/src/cssLanguageTypes.ts#L40-L43

and im gonna take another guess that this is where that gets passed in inside vscode normally:

https://github.com/microsoft/vscode/blob/17ebf65c8fb83dfeddb78013f82883e7773e664a/extensions/css-language-features/server/src/cssServer.ts#L202

if that's the case, its not so simple for us off the top of my head.

we basically run our completions logic and call the appropriate language service under the hood. in this case we'll do some logic then call through to the vsc CSS service here im guessing:

const items = this.cssService.doComplete(vscTextDocument, vscPosition, vscStylesheet);

those options inside vsc don't get passed through each language service, it seems they're resolved outside of that chain.

we'd probably have to do the options request ourselves somewhere, just the same way vsc does here:

https://github.com/microsoft/vscode/blob/17ebf65c8fb83dfeddb78013f82883e7773e664a/extensions/css-language-features/server/src/cssServer.ts#L157

then pass those in to that language service call mentioned above.

this whole message is a bunch of maybes as i've figured this out mostly from memory and bouncing around the vscode sources. if it turns out im right though it does seem its something we can solve if we figure out how that settings request works.

also keep in mind the maintenance of this repo is very slow lately. the lit team came in to help some time ago but they're of course busy like anyone else, so the review of PRs and bugs getting fixed is sadly quite slow for now.

@43081j Thanks a lot for your answer, the references look pretty useful. I don't have a good understanding at all of how all this ecosystem works, I guess I'll have to dig more into it later.

I was also thinking of a more dirty way to implement this, maybe listening to user inputs and when a completion item is selected, just using an editBuilder on the TextEditor of the TextDocument to insert the text (snippet) after the cursor
(for CSS it's just :<cursor>; and HTML ="<cursor>". )
This way seems much easier to implement. Can I have your view on that idea?

Thanks

the completions you see aren't actually created by us, which is why we can't just fix it up like that.

we basically pass the request through to the vscode CSS language service under the hood and it decides the completions.

this bug exists because we're not passing through the settings object and should be.