feat: add 'slip into the tail' feature - #51
Conversation
simple implementaion of sliding the clip being edited within in/out points (only to the left)
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a Slide timeline operation that shifts a selected clip’s source window to the playhead while preserving timeline placement and duration, synchronizing linked AV clips, validating available media tail, and updating toolbar documentation. ChangesSlide clip editing
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant SlideToolbar
participant slideClipAtPlayhead
participant syncLinkedTiming
participant PreviewMedia
User->>SlideToolbar: Click Slide
SlideToolbar->>slideClipAtPlayhead: Invoke selected-clip operation
slideClipAtPlayhead->>syncLinkedTiming: Synchronize linked AV timing
slideClipAtPlayhead->>PreviewMedia: Seek while paused
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CLAUDE.md`:
- Around line 432-435: Update the Slide (slip) source documentation to describe
tail availability using the integrated source window returned by mediaTimeAt(),
rather than the constant-speed calculation in + duration×speed. Preserve the
guidance that start and duration remain unchanged and that the UI notifies when
no unused source tail remains.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: e3d4c270-cec4-4dbf-93df-69c5d7dd39a4
📒 Files selected for processing (5)
CHANGELOG.mdCLAUDE.mdREADME.mdapp.jsindex.html
ronak-create
left a comment
ronak-create
left a comment
There was a problem hiding this comment.
The implementation is correct — mediaTimeAt() already integrates static speed and speed ramps, so preserving mediaTimeAt(c, clipEnd(c)) - c.in as the source window and re-checking it against media.duration is the right test. syncLinkedTiming() does copy in to linked partners (app.js:1239), so the linked-AV claim in the docs holds. Guards run before pushUndo(), so a rejected slip leaves no undo entry. Good.
One thing to change before merge: the name.
What this does — move the source in/out window while keeping start and duration fixed — is a slip edit. A slide edit is the opposite: it keeps the source window and moves the clip along the timeline, absorbing the difference into the neighbouring clips. Premiere, Resolve and Avid all use those two terms that way, so shipping this as "Slide" will actively mislead anyone coming from another NLE. The PR title says "slip into the tail" and CLAUDE.md hedges with "A slide (UI toolbar)" / "Slide (slip) source", so the ambiguity is already visible in the PR itself.
Could you rename to Slip — button label, #btnSlide → #btnSlip, slideClipAtPlayhead(), and the CHANGELOG/README/CLAUDE.md wording? Happy to merge right after.
Two smaller notes, neither blocking:
- It is forward-only.
t >= c.startmeansmediaTimeAt(c, t) >= c.inalways, so thesrcIn - c.in > 1e-4guard makes it impossible to slip backwards into unused head material. That matches the PR title, just worth documenting as a limitation — a real slip goes both ways. - It acts on
state.selIdonly, so with a multi-selection it slips the primary clip and silently ignores the rest, unlikesplitAtPlayhead(). Fine for a first pass.
Also: trivial CHANGELOG conflict with #50 and #41 (all three add a bullet under ### Added).
2 participants
Simple implementaion of sliding the clip being edited within in/out points (only to the left)
When a clip is selected and has in/out points set, 'slide' allows to move in/out markers of the clip simultaneously
sliding the trimmed part of the clip to the right by playhead time timelline - clip in point on the timeline. A button labelled slide has been added. It the operation is not possible, the toast is displayed.
Type of change
How was it verified?
node --check server.js && node --check app.js && node --check mcp-server.jspassesCLAUDE.md/README.mdif the schema, props, or API changedChecklist
Summary by CodeRabbit
New Features
Documentation