Something else that would be really nice would be some syntax highlighting. In the example above, I have ```ts to open the fenced code block as an info string to mark the language of the code. Kinopio doesn’t parse this, and actually puts it into the rendered card.
I know syntax highlighting can really increase a page’s JS weight, and there’s added processing whenever rendering something that would have syntax highlighting.
An idea would be that instead of rendering the “full” text for a code card, only the first few lines are rendered and you can click on it to open the card and see all of the text (maybe in a floating modal or something?)
I had kind of hoped linking a Gist would be good here, but alas, the preview image is not helpful
That’s an interesting idea it would probably handle my use cases pretty well, and it keeps the code editing / highlighting stuff off of Kinopio which is nice.
Main issue I can think of is that library has a few parameters you can pass to the embed, like data-gist-file, which would be nice to control.
the upside of iframes is the kinopio app doesn’t need big libs to process text highlighting. the downside is that bc of cors issues i don’t know the height of the content of the iframe so it’s just based proportionally on the width of the card it’s in
I love it it seems fine (especially for code blocks) for the iframe to just be scrollable like that. You wouldn’t want it to embed a site and make a gigantic card, anyway.
Would this just be for gists? Or are you considering making any site “iframeable” into a card?
creating gists is pretty high friction, so I’ve been thinking of a way to do code blocks inside cards that minimizes negative performance impacts and doesn’t change the experience for editing normal cards.
This is awesome. For syntax highlighting/selection, I always use the method where you name the type after the triple backticks:
That seems pretty conventional where codeblocks are used, and it’s nicely self-documenting. I hope that you can support that, and if so, you could consider not having a button at all.
yes my plan is to detect code from triple backticks, so no change in behaviour is necessary.
cards with triple backticks will be exempted from the card character limit.
the only new button will be on the Card itself for selecting syntax (if using the ```lang convention is too difficult or non-discoverable to do with regex).
The main thing I didn’t want to do is add a ‘code’ button to CardDetails, or a miro style ‘code block’ toolbar button.
really big code blocks that are constantly being edited may create collaboration/sync issues, but it might not ever happen IRL so i’ll address that issue when/if needed later.
I’ll probably cut down the list of languages, to only the most popular and add things ad hoc if requested. (the colored bubbles for each language are based on what github uses for that language). If you have a fav language that I should support lmk!
it would probably handle my use cases pretty well, and it keeps the code editing / highlighting stuff off of Kinopio which is nice.
it seems fine (especially for code blocks) for the iframe to just be scrollable like that. You wouldn’t want it to embed a site and make a gigantic card, anyway.
shipped. Any site that has an iframely embed should work
