feat(editor): make copy selection report failure without selection

[catlover-bot]

Summary

Make CopySelection and CopySelectionSystem report whether they actually had a selection to copy, and propagate that status through ReedlineEvent::Edit so UntilFound can continue when there is no active selection.

This follows the direction discussed in #876 of making edit operations explicit about their outcome. Editor::run_edit_command reports a dedicated EditCommandStatus with Applied and Inapplicable variants, keeping edit-command outcomes separate from EventStatus and leaving room for additional states later. This PR intentionally reports Inapplicable only for the two copy-selection commands; broader command semantics and ExecuteHostCommand remain out of scope.

Observable behavior changes only for UntilFound chains containing CopySelection or CopySelectionSystem.

Before

ReedlineEvent::Edit was always treated as Handled, even when CopySelection or CopySelectionSystem had no active selection. As a result, an UntilFound chain stopped at the copy command and never tried a fallback event such as CtrlC.

After

CopySelection and CopySelectionSystem report EditCommandStatus::Inapplicable when no selection is active. ReedlineEvent::Edit converts that result to EventStatus::Inapplicable, allowing UntilFound to try the next event. When a selection exists they report Applied, and the chain stops as before.

Regression tests cover both copy commands with and without an active selection.

Additional notes

Addresses the CopySelection / CopySelectionSystem portion of #876.

Validation performed locally:

• cargo fmt --all -- --check
• cargo clippy --locked --all-targets --all-features
• cargo test --all --all-features -- --test-threads=1 (1605 passed, 1 ignored; doctests: 30 passed)
• git diff --check

[kronberger-droid]

Nice!
One thing that I was thinking about, if there are other states an EditCommand could report?

[catlover-bot]

Yes, I think there are a few other commands that naturally have an "inapplicable" state.

For example, the original issue mentions moving to the line start when already there, cutting with no selection, and deleting a word when there is nothing to delete. Undo/redo at the end of their stacks and motions/searches that cannot find a target seem similar.

At the editor layer, I think two states may be enough for now: something like Applied and Inapplicable. I would keep EventStatus separate, since states such as exiting or host commands belong to the event layer rather than an individual EditCommand.

That also makes me think an internal enum may communicate the intent better than the bool I introduced here, while leaving room for another state later if we find a real semantic distinction.

If that matches what you had in mind, I can change this PR from bool to a small EditCommandStatus enum.

[kronberger-droid]

Yeah I am a big fan of using enums since they make it possible to easily extend it if we find out there are other states we want to represent, and they are also self documenting.
I am in favor of creating its own seperate one.
Thanks!

[catlover-bot]

Thanks! I changed the boolean result to a separate internal EditCommandStatus enum with Applied and Inapplicable variants.

The command-list path aggregates that status without short-circuiting, so all commands in an edit event still run as before, while UntilFound can see when one of them was inapplicable.

I also rebased the PR onto current main. The existing copy-selection regression tests still pass, along with the full test suite and clippy.

[kronberger-droid]

Two seperate things also:

Right now if we aggregate multiple EditCommands and the Inapplicable always win. But if we would have a Edit(vec![InsertString("abc"), CopySelection]) It reports Inapplicable after having changed the buffer.
The early return then skips abbrevation expansion and the menu block, ant the top loop skips the repaint.
Multiple answers te same question with any Handled wins.
Nothing right now hits this, but i would flip it into any-Applied-wins for now.

[catlover-bot]

Thanks for the review. I changed command-list aggregation to any-Applied-wins, matching Multiple: every command still executes, but an edit event is Inapplicable only when none of its commands applied.

I also added a regression test for an edit containing InsertString("abc") followed by CopySelection without a selection. It now returns Handled, preserves the inserted abc, and does not fall through to the next UntilFound event.

The copy-selection helpers now return EditCommandStatus directly, the enum has a short doc comment, and the four copy-selection cases have been consolidated into one rstest.

Local validation is green: 1605 tests passed, 1 ignored, 30 doctests passed, and clippy/fmt/diff checks are clean.

[kronberger-droid]

If you rebase it onto the current main I think we are ready to land it.

[catlover-bot]

Thanks! I rebased the branch onto the current main, resolved the overlap with the new auto-pair edit-command path, and force-pushed the rebased commits. The all-features tests, clippy, rustfmt, and diff checks are green locally.