feat: copy cues to the clipboard, and paste lines back over them - #111
Merged
Conversation
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
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.
Summary
The clipboard group of the Edit menu: copy cues, paste over cues, select all cues, in the positions the reference's own Edit menu gives them.
The page cannot reach the clipboard at all. Measured on 2026-09-07 inside the app's own page: WebKitGTK answers both
navigator.clipboard.writeTextandreadTextwithNotAllowedError. So the copy and the read go through the backend and GTK's own clipboard, which is already linked because Tauri pullsgtkin on Linux; nothing new is downloaded for it. Windows gets a stub that returns an error rather than one that silently succeeds, because a stub that succeeded would be a claim about a platform whose behaviour is not run here.What a copy carries is the raw line and not the text: the cue, its times and its fields, which is what makes it paste back as a cue rather than as a sentence. A paste over reads those lines behind this document's own header, so an ASS event is parsed with the
Format:line that names its columns and a VTT cue with the file's first word, and a copy from one document lands in another of the same format spelt that document's way.A second commit fixes a defect the first one had, found by asking what two cues would do where one had been checked. An SRT or VTT block is followed by a blank line and a copy of two cues left it out, so reading them back gave one cue with the other's words stuck on. The copy now puts the separator between them, and the check copies the whole file over itself and asserts all three rows come home unchanged, which a single cue could never have seen.
One defect came out of it and is fixed here. A document editor gave up every chord a text field owns,
a c v x y z, so that Ctrl+Z over a line being typed would be the document's undo. That was right while the shell had no command on the other four. The moment Ctrl+A became one, typing into the grid broke: forty-nine checks went red because selecting a field's text now selected every cue instead. Only the two history chords are taken now, which is what the keyboard spec's two contexts say and what every editor does.Changes
subtitle_copy_cues, which hands back the raw lines, andsubtitle_paste_over, which reads a fragment behind this document's own header.copyCues, which does not queue behind edits because it changes nothing, andpasteOver.How to verify it by using the app
fixtures/subtitles/srt/clean/basic-lf.srt. Edit now has Copy cues, Paste over cues and Select all cues.Verified on Linux: full gate green step by step, and the battery green at 37 spec files of 37 with 300 checks. Two mutations, each reddening its own check first: a clipboard write that puts an empty string where the lines were, and a copy that leaves out the blank line between two cues.