Skip to content
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

implement language server stub #1

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

endorama
Copy link

@endorama endorama commented Jan 2, 2024

Add a stub implementation of ES|QL language server for VSCode.

This is an experimental implementation and is not fully working (details of what works and what not are included in the folder README).

There is a major difference in the implementation compared to the Kibana plugin achieving the same functionality. They both leverage ANTLR4 grammar but Kibana is using antlr4ts while this implementation uses antlr4ng to leverage https://github.com/mike-lischke/antlr4-c3.

@dej611
Copy link

dej611 commented Jan 8, 2024

Ideally we should all use the same antlr4 tool. There's a task in Kibana to migrate the antlr4 library to use the same library as Elasticsearch with the typescript target to stay always in sync: elastic/kibana#172199

@smith
Copy link
Owner

smith commented Jan 8, 2024

I can give you write access if you want to merge this and work off of main. Whatever works for you. Thanks for doing this!

@endorama
Copy link
Author

@dej611 thanks for chiming in. I agree, it does not make sense to have different implementations. What I would also like to leverage, as that is the bulk of the implementation, is the auto-completion logic that is currently in the Kibana plugin. I think switching to core anltr4 does not present any issue but would remove the current (very small so not much of a concern) auto-completion functionalities: I choose antlr4ng to get a working prototype faster thanks to the antlr4-c3 auto-completion engine that goes on pair with it, so the current auto-completion relies on it.

@smith I don't think it make sense to continue moving forward this branch with antlr4ng if the Kibana plan is to use plain antrl4, but I also don't think it make sense to duplicate the logic. I would consider completing elastic/kibana#173612 a prerequisite to move forward with something that has enough features to be useful and does not poses an additional big maintenance burden on the language server implementation itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants