[yashranaway]

resizing the end of a zoom or other effect segment uses a minimum length of 80 pixels, which is several seconds when the timeline is zoomed out. if that minimum didn't fit before the next segment or the end of the project, the bound just pushed past them, so the drag forced the segment over its neighbour or off the end, like 10s instead of 6s.

now the minimum is capped at the space that's actually there, and a segment already past a shortened timeline keeps its range instead of being flipped. same helper covers snapped and unsnapped drags for every effect track. it's the resize side of the gap placement fix in #2744.

Confidence Score: 5/5

The PR appears safe to merge.

Summary

Updates trim_end_bounds so a large minimum length no longer pushes an effect past its neighbour or the timeline end.

• Segment ends stay within available timeline space when dragged.

_{Reviews (1) · Last reviewed commit: "fix(desktop-gpui): keep a short segment ..." · Reviewed by Greptile}

[yashranaway]

@greptileai review

[vercel]

@yashranaway is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[richiemcilroy]

Thanks @yashranaway, this is a real fix: on main trim_end_bounds (apps/desktop-gpui/src/editor_edits.rs:441) forces the end to start + min_duration even when that runs past the next segment or the timeline end, and capping at max stops the overlap. One leftover in the same scenario: when the pixel minimum does not fit, min and max both become next_start, so grabbing the end handle and dragging left still grows the segment up to its neighbour. Your first test shows it: the zoom is 2..5, requested_end 4 resolves to 6. Could you also cap min at the segment's current end, e.g. let min = (segment.start + min_duration).min(segment.end).min(max);? That is what audio_trim_end_bounds already does with bounds.min.min(segment.end). A segment that is already shorter than the zoomed-out minimum then can't shrink, but it won't grow when you drag it left, and it can still be extended up to next_start. Please update the first test so that requesting 4 keeps the end at 5.

[yashranaway]

@richiemcilroy good catch, capped min at the segment's current end in fdc5325 like the audio trim bounds, and the first test now checks requesting 4 keeps the end at 5.

[yashranaway]

@greptileai review

[richiemcilroy]

@greptileai review