-
Notifications
You must be signed in to change notification settings - Fork 58
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
Pluggable display argument providers #18
Labels
Comments
Closed
Adding the "blocked" label here for now, see #96 (comment) and #79. |
Gama11
added a commit
to vshaxe/haxe-language-server
that referenced
this issue
Jul 7, 2017
Gama11
added a commit
to vshaxe/vshaxe-build
that referenced
this issue
Jul 13, 2017
Causing issues with the display argument provider API (vshaxe/vshaxe#18).
This is now implemented. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A lot of frameworks have their own project files and an option to generate display arguments from those files. It would probably be nice to support those as an alternative to
haxe.displayConfigurations
. To make it generic, I thought we could maybe support pluggable "display arguments provider" system", wherehaxe.displayConfigurations
config is just one of them, but there's also others, like the one for openfl/lime that would be watchingproject.xml
and re-read display arguments withlime display <platform>
. I think we don't even need to touch language server for that.While this isn't implemented, we should steal/adapt the "framework notes" table from vscode-haxe:
https://github.com/jcward/vscode-haxe#framework-notes
The text was updated successfully, but these errors were encountered: