-
Notifications
You must be signed in to change notification settings - Fork 480
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
@gif
block
#1675
Comments
I realized asciinema is based on a simple JSON-based specification: https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md. So I quickly whipped up a Julia implementation, which lets us avoid issues 1 and 6. The inline HTML player is apache licensed so no issues there. Then I went ahead and looked at the Documenter internals and made an So the only remaining issue AFAIK is getting the JS loaded in the correct order (issue 4), and not relying too much on Documenter.jl internals. And testing it. It works for my example at least: ericphanson/TravelingSalesmanExact.jl#17 (rendered here: https://ericphanson.github.io/TravelingSalesmanExact.jl/dev/) |
Couldn't Asciicast.jl just define a type that is showable for text/html? |
Yes but then you can’t use setup blocks or share state between examples and gifs etc (https://ericphanson.github.io/Asciicast.jl/dev/#Example-with-a-named-block). Well I guess technically if I’m messing with internals then I can still, but I don’t really get what the point is in that case. But that might still be nice if someone wanted to use it in Pluto or something. |
This is really neat, but I am not sure we want this in core Documenter. I would suggest implementing this as a separate package which adds a new DocumenterCitations can probably offer some inspiration if need be, and #1648 is probably also be relevant for this. |
Ok, sounds good! Is the ExpanderPipeline considered stable by the way? Also I already did implement it in Asciicast.jl 😄 |
It's de facto stable... as in no-one has broken it ever. But we may in the future. Documenter's internals are not really documented and need refactoring if we truly want to support plugins long-term. However, that's unlikely to happen any time too soon, and once it does, we'll try to do it in a way to keep the plugins working, including making PRs against the plugins to update the parts where it interacts with Documenter. All that said, what could be nice is a PkgEval-like CI job here that would test whether the latest version of each plugin still passes all its tests when running against |
It would be great to have an option for APNG as well. |
As a followup, Asciicast.jl is updated for Documenter v1.0 and is registered (xref https://discourse.julialang.org/t/ann-asciicast-jl/107529).
I will PR a workflow for this! |
I think it would be awesome if there was an
@gif
block that acted like an@repl
but instead of printing the commands linearly, it generated an asciinema gif and inserted it. I made a prototype of sorts in ericphanson/TravelingSalesmanExact.jl#16. See it in action here: https://ericphanson.github.io/TravelingSalesmanExact.jl/v0.3.7/#Example, or in a screenshot:There are a lot of things to be unhappy with in my hacky version:
@repl 1
etc).include("docs/make.jl")
repeatedly when developing docs). I therefore setup caching system to prevent re-making the same gif over and over, but I'm not sure it's robust enough for Documenter.jl's large userbase@example
and run a string macro.However, I still think the result is super cool! Any ideas on how to get some (better?) version of this into Documenter.jl?
The text was updated successfully, but these errors were encountered: