enhancement: extend F6 to Rename/Move (mc-parity, editable destination dialog)

[efimsky]

Type: Enhancement (UX, mc parity)

Location: tnc/app.py:do_move / _do_file_operation, tnc/panel.py, menu wiring

Problem

In Midnight Commander, F6 is labelled "RenMov" and serves both Rename and Move from a single key. The dialog opens with a single editable destination path field, pre-filled with the other panel's path + the source filename. The user can:

• Keep the path, change the filename → rename in place
• Change the directory, keep the filename → move
• Change both → move + rename in one step

This is a long-standing mc convention and the keystroke users rely on most when reorganizing files.

In tnc today, F6 is Move-only: the destination is silently always the other panel's path with the same filename, and rename is hidden behind File menu → Rename (no F-key, two extra steps). Users coming from mc hit F6 expecting the rename dialog and instead either get nothing useful (when both panels point at the same dir, the operation tries to copy a file onto itself) or move blindly without the chance to retitle the file at the destination.

CLAUDE.md explicitly says "Midnight Commander (mc) is the reference for all UX decisions" — F6's current behavior diverges from that reference.

Proposed enhancement

Replace the current F6 confirmation with an editable destination dialog (mc-parity):

1. Pressing F6 on a single highlighted entry opens an input dialog whose default value is <other_panel.path>/<source_name>.
2. User can edit any part of the path. On accept:
   • If parent directory equals source directory → call the existing rename path (Panel.rename_file / equivalent).
   • Otherwise → call the existing move path with the typed destination (preserving rename when the basename differs).
   • Empty input or unchanged input → cancel (no-op), same as Esc.
3. For multi-file selections, F6 keeps the current behavior: prompt for a destination directory only (no per-file rename), defaulted to the other panel.
4. Function bar label changes from F6 Move to F6 RenMov to match mc and signal the new affordance.

Acceptance criteria

• F6 with one entry selected opens an editable destination input pre-filled with <other_panel.path>/<source_name>.
• Editing only the basename (parent dir unchanged) performs a rename in the source directory; both panels refresh.
• Editing the parent dir performs a move; if the basename also changed, the move includes the rename.
• F6 with multiple entries selected behaves like the current move (destination is a directory; no per-entry rename).
• F6 against .. is a no-op (consistent with current behavior).
• Esc cancels with no filesystem change.
• Function bar shows F6 RenMov.
• Existing keyboard shortcut for menu-driven Rename keeps working unchanged (no breakage of File → Rename).
• All existing F6 / move tests still pass; new tests cover the rename-via-F6, move-via-F6, and move+rename-via-F6 paths.

Out of scope (v1)

• Multi-file F6 with per-entry rename (mc has this behind a different flow; not a v1 goal).
• Tab-completion inside the destination input.
• Path-shorthand expansion beyond what pathlib.Path already does (e.g., ~ expansion can be a follow-up if not already supported by the input dialog).
• Visual indicator of "this will rename" vs "this will move" — text-only confirmation is fine for v1; the result is unambiguous from the entered path.

References

• mc keybindings: F6 = RenMov (mc --help-keys)
• tnc convention reference: CLAUDE.md → "Midnight Commander (mc) is the reference for all UX decisions"
• Related code: tnc/app.py:do_move, tnc/app.py:_do_file_operation, tnc/panel.py:rename_file, tnc/function_bar.py:_DEFAULT_LABELS

[efimsky]

Investigation summary

Confirmed scope and code paths:

• F6 today routes via Action.MOVE → App.do_move (tnc/app.py:768) → _do_file_operation template method which always uses move_files_with_overwrite and treats the destination as other_panel.path (no editable dest, no rename). Multi-file and single-file go through the same path.
• Rename in tnc lives at tnc/app.py:_prompt_rename (:1363) and uses rename_file(parent_dir, old_name, new_name) from tnc/file_ops.py:1034. It validates the new name (no path separator, etc.) and refuses if dest already exists (with case-insensitive-FS exception via samefile).
• Modal we'll reuse: input_dialog (tnc/dialog.py) — same one used by _prompt_rename, _prompt_mkdir, etc.
• Function bar label: tnc/function_bar.py:_DEFAULT_LABELS['F6'] = 'Move' → change to 'RenMov'.

Alternatives considered

Three approaches to the move+rename single-file flow

A. shutil.move with explicit overwrite prompt (selected)

• Pros: shutil.move(src, dst) natively handles all three cases (rename / move / move+rename) in one call. No duplicated logic. Cross-device fallback (copy+delete) is built in.
• Cons: We bypass the existing move_files_with_overwrite infrastructure for single-file F6 — need to pre-check dest existence and prompt with confirm_dialog ourselves.
• Why chosen: mc-spec semantics map cleanly to one shutil.move call. Cleanest single-method implementation.

B. Two-step: existing move_files_with_overwrite then rename_file

• Pros: Reuses the polished OverwriteHandler flow.
• Cons: If move succeeds and rename fails, we leave a partial state (moved file with old name). Atomicity is worse than (A).
• Why rejected: Worse failure semantics than shutil.move (which is atomic on the same filesystem).

C. Extend move_files_with_overwrite to accept per-file dest names

• Pros: Centralized — both bulk and single-file flows share the same code path.
• Cons: API change; ripples into copy_files_with_overwrite for symmetry; adds a per-file mapping argument that's only used by single-file F6 in v1.
• Why rejected: YAGNI. Per-file rename in bulk operations is explicitly OOS for v1.

Out of scope (v1)

• Multi-file F6 with per-entry rename (mc has it behind a different flow; our acceptance criteria explicitly preserve the current multi-file behavior).
• Tab-completion inside the destination input.
• ~-expansion or environment-variable interpolation in the path beyond what pathlib.Path already does.
• Visual indicator distinguishing "this will rename" vs "this will move" — the entered path is unambiguous.
• Replacing the existing menu-driven File → Rename flow. It stays unchanged so users who don't know about F6 RenMov can still rename via the menu.

Complexity assessment

Scope: Medium
Affected areas:
  ~ tnc/app.py            — do_move branches by file count; new _do_single_rename_or_move
  ~ tnc/function_bar.py   — F6 label 'Move' → 'RenMov'
  + tests/test_move.py or new tests/test_rename_or_move.py — F6 single-file tests
Estimated changes: 3 files, ~200 lines (incl. tests)
Risk level: Low (multi-file F6 path unchanged; rename_file unchanged; menu Rename unchanged)
Type: Backend (terminal app, file ops)