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
- Start a server (
jcode serve) and attach a client (jcode connect).
- Type a draft in the input box, move the cursor to the middle.
- 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:
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).
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 serve+jcode connect(server/client mode; log confirmsprovider=remote)Reproduction
jcode serve) and attach a client (jcode connect).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 path —
crates/jcode-tui/src/tui/app/input.rs:handle_key_corecallshandle_pre_control_shortcuts(which handles plain Ctrl+K →delete_input_to_endfor non-empty drafts, with an explicit Shift guard so Ctrl+Shift+K still scrolls) before the navigation/scroll handlers that claim Ctrl+K viaprompt_jump.handle_pre_control_shortcutsaround line 2212,delete_input_to_endaround line 1954.Remote path —
crates/jcode-tui/src/tui/app/remote/key_handling.rs:handle_pre_control_shortcutsequivalent.prompt_jumpis reached first (around line 558), and it claims Ctrl+K as "previous prompt" whenever the input has any navigation modifier (Ctrl included), sodelete_input_to_endis never reached.The hint appears because
observe_known_hotkeyruns 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.rsbefore theprompt_jumpcheck:Same for the disconnected path in
remote.rs(handle_disconnected_key_internalcallshandle_navigation_shortcutsfirst, which also claims Ctrl+K viaprompt_jumpbeforehandle_control_keyruns).