-
Notifications
You must be signed in to change notification settings - Fork 11
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
RFC 0008: Builtin blocktypes #262
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, looks really intuitive to me! Also hyped for the extension of this work towards composite blocks! ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. We should probably look into the docs as well for the io-type case changes, although we don't have a real documentation therefore yet.
Btw, I'm missing a mechanism to add documentation (description and examples) that we previously had in the |
For now, I think it would be fine to leave that aspect in the langauge server (i.e. the language server "magically" provides documentation for builtin block types). On the long run, we could use structured comments to describe documentation, similar to how it's done in programming languages. Recently I've noticed, that Langium offers some kind of JSDoc support, but I haven't looked into it so far: https://github.com/langium/langium/blob/main/packages/langium/CHANGELOG.md#jsdoc-support |
We should merge this, right @georg-schwarz ? I can take over creating an implementation issue. |
|-------------|----------------------| | ||
| Feature Tag | `builtin-blocktypes` | | ||
| Status | `DISCUSSION` | <!-- Possible values: DRAFT, DISCUSSION, ACCEPTED, REJECTED --> | ||
| Responsible | `@felix-oq` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably change the responsible person.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in the latest commit, I think then we can go like this, right? If we need to iterate on this I'd rather create a new PR.
Preparation for #217
Rendered markdown: https://github.com/jvalue/jayvee/blob/rfc-0008-builtin-blocktypes/rfc/0008-builtin-blocktypes/README.md