Change the demo gifs to videos and update them for the newly added features - #6073
Open
stefanhaller wants to merge 8 commits into
Open
stefanhaller wants to merge 8 commits into
stefanhaller wants to merge 8 commits into
Conversation
stefanhaller
added this pull request to stack #6027
September 27, 2026 13:14
When running the demos at a hight of 35, as the new recording mechanism will, this demo failed because the commits list was too small to show both commits at the same time, and NavigateToLine has a bug that prevents it from finding it by going to the top and pressing down until it matches. We are going to fix that bug in the next commit for similar future situations, but we also solve the problem here by setting the side panels to accordion mode so that more commits are visible; this looks better for this demo anyway.
NavigateToLine looks for its target among the lines the view has rendered. When a list is scrolled, the view holds only the part of it that is on screen, so the target may not be among them. For that case the helper jumps to the top of the list and walks down instead. That walk presses a key before it looks, so it never sees the item it starts on, which after jumping is the first item of the list. A target sitting there is reported as missing. The shorter the terminal, the more of a list is scrolled out of view and the more often that walk is needed, so this surfaced once the demos began running in a 35 line terminal. Check the line the walk starts on before moving off it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
How a demo behaves depends on how much of a list fits on the screen, and `just e2e` ran demos on a 150x100 screen while we record them at 120x35. So a demo could pass the test suite and still fail partway through a recording, and there was no way to find out short of recording it. Give a demo the recording size when it doesn't ask for a size of its own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
We don't bother rendering the updated or new demos yet, because we are about to change them to a different format.
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. 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. Two things about the frame. Pad the bottom, 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. And cut the end: vhs records until the marker reaches the screen, by which time lazygit has exited and the shell has painted its prompt back over the demo. A browser holds the last frame of a video once it has played to the end, so leaving those frames in would end every demo on a terminal prompt and leave it there. 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, at 1866x1230 and 25 fps against 1140x828 and about 5 fps. 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>
stefanhaller
force-pushed
the
rerecord-demos-and-update-readme
branch
from
September 27, 2026 16:27
03df360 to
002b3bc
Compare
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.
The demo videos were rendered as animated gifs, which is less than ideal, because they start playing automatically, they loop but users can't tell when they start over from the beginning, and they can't be paused or rewound.
Convert them to videos instead so that users see a playhead and the usual player controls. Leave a bit of room at the bottom for those controls; different browsers render those differently, so it's a bit of a best effort solution.
Also take this opportunity to update some of the demos for the changed functionality of #6035, #6039 and others.