-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
Add ability to run code examples in the playground #340
Comments
I went looking through the mkdocs material for this functionality and didn't see it. I'm going to reach out to the author and see if I missed the functionality, otherwise, I'll put in a feature request. |
So this is the report: We can do some custom css and javascript. That's not really my thing, but someone could take this on. |
There doesn't seem to be a native option to add any other button than "copy" and "select" with the latter being sponsors-only:
Others have also wished for this functionality to become more generalized: squidfunk/mkdocs-material#4005 The only solution given there is to fork the theme. However, one could add custom JavaScript to add this behavior: https://squidfunk.github.io/mkdocs-material/customization/#additional-javascript To achieve a quick and easy solution, we could add buttons to all code blocks manually Something, that would be more work but would prevent us from duplicating the code (once inside the code block and once URL-encoded in the button), would be to move the code to separate files and embed them. Alternatively, it could be gists. This could also help in cases where the examples are longer than the URL is allowed to be by the browser (I don't know if we would run into that problem) 🤔 Or should the preview be in the tutorial, not just (in a new tab) in the playground? |
We use the insiders build. So that is available as an option. |
Yeah, but that is only the "select" button, not the "play"/"run"/"execute" button |
The other nice thing about the idea of moving the code examples to separate Pony files, is that we easily could start including testing to prove that all the examples compile. |
If it helps, this can be done in a separate PR, when other questions are not yet answered |
@shaedrich are you interesting in tackling this? if yes, what additional information or discussion do you need from us? |
@SeanTAllen I am indeed. The questions asked above still stand:
|
I'd prefer
my worry with gists is... that seems hard to maintain as the code is "somewhere else". which i think means, yes files is best. Looking at the tutorial I seriously doubt any of our code is going to hit a URL limit so... I'd love to see the code stored in files and then the content put into the block at build time. then we can use ponyc to verify that all the code samples build. we can have the code inline in the block in the built site and do preloaded code inline. given that our code samples are in the hundreds to low thousands for the examples, i think that would work. @jemc what are your thoughts? |
Grabbing the code from files could easily be implemented here:
There's even an option to embed external files in the code block widget: https://squidfunk.github.io/mkdocs-material/reference/code-blocks/#embedding-external-files |
Yes, if it's possible I'd want the code to be in files in this repo (rather than gists) and get incorporated at tutorial build time. And get tested with ponyc at CI time. |
Possible follow-up features
→ Custom code fence: #555 |
…ippet from URL by file name (#205) See ponylang/pony-tutorial#340 > [!WARNING] Will only work, after #222 has been merged. Example: https://playground.ponylang.io/?snippet=hello-world-main.pony Co-authored-by: Joe Eli McIlvain <[email protected]> --------- Co-authored-by: Matthias Wahl <[email protected]> Co-authored-by: Joe Eli McIlvain <[email protected]>
From #549:
|
See #550 for a possible implementation |
One thing, I just thought about: When we have a |
Discussed on the sync call - while it isn't super helpful to anyone to create a few gist from a github-sourced snippet, it's not a problem per se, and it would potentially be confusing (or a maintenance problem) to add special case behavior to disable that. |
We had this sort of on the old tutorial but that didn't get migrated over.
The text was updated successfully, but these errors were encountered: