Re-record demos - #6050
Draft
stefanhaller wants to merge 10 commits into
Draft
Re-record demos#6050stefanhaller wants to merge 10 commits into
stefanhaller wants to merge 10 commits into
Conversation
The integration test config asks for `black` inactive borders. In a recording that comes out as a mid grey, because the recording theme remaps the terminal's black to #7a7a7a. In an ordinary terminal it is real black, so when you watch a test with `just e2e-cli` the inactive frames all but disappear against the background. Name the grey directly instead (but a little bit brighter than the #7a we had before), so that the frames look the same either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The demo gifs in the README start on their own, loop without telling the reader where a run begins, and give no way to pause, seek or replay. A video with the browser's own controls fixes all three, but GitHub plays a video in a README only when it is served from its own attachment store. If you commit one to the assets branch and link it the way we link the images, GitHub drops the whole <video> element when it renders the page. Replace terminalizer with vhs. vhs records the demo straight to mp4 rather than going through a gif, and it takes the terminal size, font and colours from demo/settings.tape. Then upload the result from the endpoint that GitHub's own drag-and-drop upload posts to, and print the tag to paste into the page. The recording is sharper and smaller than the gif it replaces. It runs at 1866x1140 and 25 fps for 297K, against 1140x828 and about 5 fps for 461K. It also costs the reader nothing until they press play, whereas the gifs are fetched every time the README is opened. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Readers can pause, seek and replay it now, and it no longer starts on its own. The other demos stay as gifs until they are re-recorded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
stefanhaller
force-pushed
the
rerecord-demos
branch
from
September 22, 2026 18:59
c05fa48 to
84dd4b4
Compare
…tore Record demos with vhs and publish them to GitHub's attachment store The demo gifs in the README start on their own, loop without telling the reader where a run begins, and give no way to pause, seek or replay. A video with the browser's own controls fixes all three, but GitHub plays a video in a README only when it is served from its own attachment store. If you commit one to the assets branch and link it the way we link the images, GitHub drops the whole <video> element when it renders the page. Replace terminalizer with vhs. vhs records the demo straight to mp4 rather than going through a gif, and it takes the terminal size, font and colours from demo/settings.tape. Then upload the result from the endpoint that GitHub's own drag-and-drop upload posts to, and print the tag to paste into the page. Uploading alone is not enough. An attachment is readable only by people who are signed in to GitHub until a posted comment in the repository refers to it, and a README on a branch does not count. So post each recording to a collecting issue and wait until the video can be fetched without a token. Miss that step and the video plays for whoever recorded it and 404s for every other reader. Pad the bottom of the frame as well, because the browser draws its playback controls over the video and they are tall enough to cover the line where the demos put their captions. The recording is sharper and smaller than the gif it replaces. It runs at 1866x1290 and 25 fps for 304K, against 1140x828 and about 5 fps for 461K. It also costs the reader nothing until they press play, whereas the gifs are fetched every time the README is opened. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…tore Record demos with vhs and publish them to GitHub's attachment store The demo gifs in the README start on their own, loop without telling the reader where a run begins, and give no way to pause, seek or replay. A video with the browser's own controls fixes all three, but GitHub plays a video in a README only when it is served from its own attachment store. If you commit one to the assets branch and link it the way we link the images, GitHub drops the whole <video> element when it renders the page. Replace terminalizer with vhs. vhs records the demo straight to mp4 rather than going through a gif, and it takes the terminal size, font and colours from demo/settings.tape. Then upload the result from the endpoint that GitHub's own drag-and-drop upload posts to, and print the tag to paste into the page. Uploading alone is not enough. An attachment is readable only by people who are signed in to GitHub until a posted comment in the repository refers to it, and a README on a branch does not count. So post each recording to a collecting issue and wait until the video can be fetched without a token. Miss that step and the video plays for whoever recorded it and 404s for every other reader. Pad the bottom of the frame as well, because the browser draws its playback controls over the video and they are tall enough to cover the line where the demos put their captions. Pass --no-upload while you are still working on how a demo looks. That writes the video to demo/output and stops, so trying out a colour or a font costs nothing but the recording itself. The recording is sharper and smaller than the gif it replaces. It runs at 1866x1230 and 25 fps for 306K, against 1140x828 and about 5 fps for 461K. It also costs the reader nothing until they press play, whereas the gifs are fetched every time the README is opened. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Changing demo/settings.tape, or anything about how lazygit looks, dates every recording at once, and re-recording them one at a time means running the recorder fifteen times and pasting fifteen new URLs. Attachment URLs say nothing about where they came from, so there is also nothing to tell you which demo a video in the README is of. Name the demo in a comment above each video. GitHub drops the comment when it renders the page, so it costs the reader nothing, and it gives us a way back from a page to the demo that produced it. Then walk those comments, re-record each demo and rewrite the URL below it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A test PR for rerecording the demos for a better user experience. Might turn into a real PR if this works out.