Skip to content

Zed Shift+Enter sends LF and bypasses Ctrl+J newline binding #20898

@misrtjakub

Description

@misrtjakub

What issue are you seeing?

#20535 restored the alt-enter newline alias for #20501, but it does not cover the Zed integrated terminal case from #20555.

In Zed on Windows, Shift+Enter and Ctrl+J can be reported as LF / U+000A with no modifiers. The default keymap already includes ctrl-j for editor.insert_newline, but key_hint.rs only normalizes a subset of C0 control characters and does not map LF to Ctrl+J. As a result, the existing ctrl-j newline binding does not match this terminal event.

Current main still has no LF mapping in c0_control_char_to_ctrl_char:

fn c0_control_char_to_ctrl_char(ch: char) -> Option<char> {
    match ch {
        '\u{0002}' => Some('b'),
        '\u{0006}' => Some('f'),
        '\u{000e}' => Some('n'),
        '\u{0010}' => Some('p'),
        '\u{0012}' => Some('r'),
        '\u{0013}' => Some('s'),
        _ => None,
    }
}

Expected behavior

KeyCode::Char('\u{000a}') with no modifiers should normalize to logical Ctrl+J, matching the existing editor.insert_newline binding.

Suggested fix

Add the LF mapping:

'\u{000a}' => Some('j'),

I have a small patch with a focused unit test here:

https://github.com/openai/codex/compare/main...misrtjakub:fix/codex-shift-enter-newline?expand=1

I cannot open a PR because this repository currently limits PR creation to collaborators.

Metadata

Metadata

Assignees

Labels

TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displaybugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions