Shift tool changes to make retiming easier

[dvdkon]

This PR makes two changes to the Shift Times dialog:

• It adds "Shift to match selection" option, which shifts lines so that the first line selected's start time matches the beginning of the currently selected range in the audio panel. This allows users to simply pick where a known subtitle should start instead of having to calculate an offset.
• It changes the "Affect selection onward" option to use start times instead of line order, because some subtitles have out-of-order lines, but when retiming you probably want to affect lines chronologically.

As with my other PR, I'm still new to Aegisub, so I'm open to suggestions.

[arch1t3cht]

Thanks for the PR. Without looking at the code closely yet, I have a couple of thoughts on the features themselves:

Starting with the second commit: Generally I'm very hesitant to change existing behavior in Aegisub in opinionated ways (it always breaks someone's workflow), especially when the alternative behavior could also be achieved in a Lua script.
(For example, you may be interested in my personal Timing Binds script which implements something fairly similar as an automation script. You could also adapt this to use the audio selection instead.)

That said, this is an instance where it's hard to imagine a case where someone would rely on the previous behavior ("selection onward" meaning "all lines below the selection in the file") in a way that's incompatible with the proposed change ("selection onward" meaning "all lines starting after the selection"), so I'd be willing to make this change in this case.

...I wrote the above paragraph and then asked around and, indeed, one person described how this change would indeed break their existing workflow. Not significantly so; a user can always just manually extend the selection to the bottom of the file; but that's another couple of clicks that weren't necessary before.

The case in question is one where:
a) We have a show with multiple episodes, all of which have the exact same (or very similar) timing for some elements (like the opening / ending / some intro narration)
b) The source video's timing differs from the final encode's timing (e.g. because the encode cuts out some logos at the start)
c) The file has chapter marker lines at the top

In this case, the workflow consisted of:
a) Timing on the source file but copying over some common lines, including chapter markers, from the final subtitles of the previous episode (which are hence already timed to the final video)
b) Then later shifting everything below the chapters and intro narration to match the final video file.
In this case, the "Shift lines below selection" behavior is actually necessary since "Shift lines starting after selection" would also (incorrectly) shift the chapter marker at the top.

Which, yes, is an extremely specific use case, but a real use case nonetheless.

In principle this use case may be specific enough to accept breaking it (especially since your proposed change enables uses that weren't easily possible before, while the old behavior can still be emulated somewhat easily), but maybe the better compromise is to Just Add An Option To Reenable Spacebar Heating, i.e. to have two radio options "Selection onwards" and a "Selection and below" representing the two different behaviors.

---

As for the first commit, first of all there are some concerns with the current implementation:

• "To match selection" is quite confusing as a description; this should at least be "To match audio selection".
• The case where there is no audio loaded is currently not being handled. The option should probably just be greyed out in this case.

But my main concerns are about whether this fits well into Aegisub:

• Using the audio selection to input a reference point does feel a bit hacky. I can see how there's no real better alternative, but one big issue with this method is that it's only really useful when the user has Auto-Commit disabled (which many users don't) - otherwise you cannot "input" a time without changing an existing line's start/end times. This is not a dealbreaker by itself but it's something to keep in mind.
• There is already a command time/frame/current that shifts the selection so that the active line starts at the current video frame. This is quite similar in spirit to your suggested feature but the details differ:
  • Most obviously, the existing command uses the current video frame as a reference while your feature would use the audio selection. The benefit of using the audio selection is that you do not need to have a video loaded to use it, and in principle it'd be nice to have two versions of these commands, one with a video reference and one with an audio reference.
  • The existing command is a command, which in particular makes it hotkeyable, while your added feature isn't.
  • On the other hand, your added feature allows the user to pick between "All lines" / "Selection" / "Selection onwards", which the existing command does not. One could add three variants for this command but that's a slippery slope and easily spirals into option bloat - at that point it may be better to write an automation script (like I have).
  • The existing command uses the active line's start time as the shift anchor, while your added feature uses the selection's minimum start time. This is a case where I think the existing command's logic is strictly better, since it's more explicit (and hence less likely to cause surprising behavior) and more flexible.

So, while I'm not opposed in principle to adding a feature like this, the main questions are:

• Is there a realistic use case where the existing time/frame/current command is insufficient but where your added feature would help? Is that use case common enough to be worth addressing in Aegisub itself rather than in an automation script?

  In particular, I'd be interested in your exact use case for this.

• Is that feature helpful enough to be worth the problems with using the audio selection as an input?

• Can your feature be added in a way that's not too inconsistent with the time/frame/current command?

I don't have answers to these questions yet, it'll depend a lot on what exact problem you're trying to solve with this. I just want to explain my thoughts on this.

Again, I'm not opposed to adding this in principle, but if it's added it should somehow be consistent with the existing time/frame/current feature. Since that feature is, well, existing behavior, that'd probably mean a command to shift to the audio selection (say time/audio/current) would need to match the existing command's behavior where it can. If that's not enough for your use case (say if you need "selection onwards" behavior), then another option would be to then also add both the "shift by video frame" and "shift by audio selection" options to the "Shift Times" dialog.