Skip to content

Ctrl+K does not delete to end of line in remote (server/client) sessions — remote dispatch path lacks kill-to-end before prompt_jump #832

Description

@shanexu

Summary

Ctrl+K does not delete to end of line in remote (server/client) sessions, even though it works in local sessions. A "⌨ Ctrl+K → delete to the end of the input" hint is shown, but the actual behavior is prompt jump (scroll to previous prompt).

Environment

  • jcode v0.68.0 (fcf5390), macOS
  • Running as jcode serve + jcode connect (server/client mode; log confirms provider=remote)

Reproduction

  1. Start a server (jcode serve) and attach a client (jcode connect).
  2. Type a draft in the input box, move the cursor to the middle.
  3. Press Ctrl+K.

Expected: text from the cursor to the end of the input is deleted (kill to end of line, Emacs habit).

Actual: the cursor jumps to the previous prompt. A transient hint "Ctrl+K → delete to the end of the input" appears first, but the delete never happens.

Note: Ctrl+A / Ctrl+E / Ctrl+U / Ctrl+W all work correctly in the same remote session.

Root cause

jcode has two key-dispatch paths, and only the local one implements kill-to-end:

  • Local pathcrates/jcode-tui/src/tui/app/input.rs:

    • handle_key_core calls handle_pre_control_shortcuts (which handles plain Ctrl+K → delete_input_to_end for non-empty drafts, with an explicit Shift guard so Ctrl+Shift+K still scrolls) before the navigation/scroll handlers that claim Ctrl+K via prompt_jump.
    • Relevant code: handle_pre_control_shortcuts around line 2212, delete_input_to_end around line 1954.
  • Remote pathcrates/jcode-tui/src/tui/app/remote/key_handling.rs:

    • There is no handle_pre_control_shortcuts equivalent. prompt_jump is reached first (around line 558), and it claims Ctrl+K as "previous prompt" whenever the input has any navigation modifier (Ctrl included), so delete_input_to_end is never reached.
    • Confirmed identical in v0.68.0 and current master (v0.70.1).

The hint appears because observe_known_hotkey runs early in the remote handler and resolves Ctrl+K via the contextual lookup (hotkey_feedback.rs, contextual_lookup: "Plain Ctrl+K kills to end of line while a draft exists"), which reflects the intended behavior — so the UI advertises kill-to-end while the dispatch actually performs prompt jump.

Suggested fix

Mirror the local path in remote/key_handling.rs before the prompt_jump check:

// Plain Ctrl+K kills to end of line (mirrors input.rs handle_pre_control_shortcuts).
// Must run before prompt_jump, which would otherwise claim Ctrl+K.
if modifiers.contains(KeyModifiers::CONTROL)
    && !modifiers.contains(KeyModifiers::SHIFT)
    && matches!(code, KeyCode::Char('k'))
    && !app.input.is_empty()
{
    input::delete_input_to_end(app);
    return Ok(());
}

Same for the disconnected path in remote.rs (handle_disconnected_key_internal calls handle_navigation_shortcuts first, which also claims Ctrl+K via prompt_jump before handle_control_key runs).

Metadata

Metadata

Assignees

No one assigned

    Labels

    autonomous: likelyProbably hands-off: clearly worth fixing, agent can do it, minor judgment needed.bugSomething isn't workingtriage: fixed-pending-releaseFixed in code/committed; will close automatically on next releasetriage: reproducibleClear repro + clear fix path

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions