feat: allow cycle rename

[likelikeslike]

Which issue does this PR resolve?

Resolves #4034

Rationale of this PR

This PR is a follow of issue #4034, which introduces the cycle rename groups to solve the cycle rename during bulk renaming. By adding a temp filename for each cycle group, it breaks and can be renamed as normal chain renaming.

Checklist

• I have read CONTRIBUTING.md

[likelikeslike]

Hi @sxyazi, would you mind reviewing this PR when you have some time? I'd really appreciate it. Thanks.

[dw-xdy]

@likelikeslike great feature! I ran into this issue myself some time ago — I wanted to swap the names of two images, and it would have been great if that were supported.

However, I do see a problem here: Yazi currently doesn't have an undo feature (except within the input context). Although Yazi has a final confirmation step in place, I think the vast majority of people won't bother to double-check it. So my concern is that — without an undo mechanism — performing bulk cyclic rename operations on a large number of files is a fairly risky move.

Unfortunately, in #404, Yazi's maintainer sxyazi has already made it clear that undo support will not be implemented.

I'd like to hear your thoughts on this concern.

[likelikeslike]

@likelikeslike great feature! I ran into this issue myself some time ago — I wanted to swap the names of two images, and it would have been great if that were supported.

However, I do see a problem here: Yazi currently doesn't have an undo feature (except within the input context). Although Yazi has a final confirmation step in place, I think the vast majority of people won't bother to double-check it. So my concern is that — without an undo mechanism — performing bulk cyclic rename operations on a large number of files is a fairly risky move.

Unfortunately, in #404, Yazi's maintainer sxyazi has already made it clear that undo support will not be implemented.

I'd like to hear your thoughts on this concern.

The only change here is that, for each cyclic rename group, a temporary filename is introduced. It then serves as the normal bulk rename operation. So the concern you mentioned can also occur in a normal bulk rename, not just during cyclic renames.

[dw-xdy]

@likelikeslike Thanks for the quick reply. :)

Yes, you're absolutely right. But I think it's worth distinguishing between ordinary batch renaming and cyclic renaming — because the risks are quite different.

With ordinary batch renaming, the changes are typically applied within each line independently — e.g., adding a prefix, replacing text, or changing file extensions. There's no dependency between lines, so users generally have a clear idea of what they're doing, and the chance of errors is relatively low.

Cyclic renaming, on the other hand, involves swapping names between lines, and the filenames often follow a certain pattern or sequence. This interdependency makes mistakes much more likely — and if something goes wrong, cleaning up the mess afterward can be quite painful.

That's really the core of my concern.

[likelikeslike]

@dw-xdy I do agree. But since yazi has no global undo mechanism, building a localized undo specifically for cyclic renames would feel out of place.

So I'd rather not add an undo onto this PR. The cyclic-rename support itself only makes up for a correctness gap (a valid intent like a → b, b → a currently fails), and the safety/undo question is really a broader, app-wide decision that's best left to @sxyazi rather than solved here.