-
Notifications
You must be signed in to change notification settings - Fork 41
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
Are auto-closing features not working or are they just not implemented? #290
Comments
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). That would make this feature a little more lit than it already is. Thanks |
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: and im gonna take another guess that this is where that gets passed in inside vscode normally: 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: lit-analyzer/packages/lit-analyzer/src/lib/analyze/document-analyzer/css/lit-css-vscode-service.ts Line 126 in 92c084d
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: 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 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. |
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 selectdisplay
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) :
What I get in an html file (after completion) :
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)
The text was updated successfully, but these errors were encountered: