keypad enter sends ctrl-c on macos, again

[raivivek]

What Operating System(s) are you seeing this problem on?

Linux X11, macOS

WezTerm version

wezterm 20220629-072326-e6efec82

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Hi -- thanks for Wezterm. I am having an issue with running commands by pasting them directly into the terminal. If I copy anything, a command for example, and paste it into terminal and press "Enter" (without changing anything), the command is not run. But if I delete a character and retype it or just move the cursor bar and then press "enter", the command is executed. Please see an example below:

• First line is "paste" + "Enter"
• Second line is same as above
• Third line is move cursor bar a single character to left and then press enter

What seems to be the issue? Thanks!

Note: This was created following discussion here

To Reproduce

1. Copy any command from browser or elsewhere
2. Paste it in terminal and press enter
3. Command is not run

The command is run successfully if I press the "up" key and run it again. Or if I press left/right arrow key or somehow "touch" the pasted letters and press enter.

Configuration

local wezterm = require 'wezterm';

return {
  font = wezterm.font_with_fallback({
    { family="Operator Mono", weight="DemiLight", stretch="Normal", style="Normal" },
    { family="Fira Code Retina" },
    { family="FiraCode Nerd Retina" }
  }),
  font_size = 14,
  initial_cols = 100,
  initial_rows = 40,
  freetype_load_flags = "NO_HINTING",
  default_cursor_style = "BlinkingBar",
  color_scheme = "Dracula",
  window_padding = {
        top = 1,
        bottom = 0,
        left = 0,
        right = 0,
    },
  window_frame = {
    font_size = 13
  },
  colors = {
    tab_bar = {
      active_tab = {
    bg_color = "#2b2042",
    fg_color = "#e0e0e0",
    intensity = "Bold",
    italic = false
      },
      inactive_tab = {
    bg_color = "#080808",
    fg_color = "#808080",
    intensity = "Half",
      }
    },
  },
  inactive_pane_hsb = {
    saturation = 0.8,
    brightness = 0.7,
  },
  mouse_bindings = {
    { event={Down={streak=4, button="Left"}},
      action={SelectTextAtMouseCursor="SemanticZone"},
      mods="NONE"
    },
  },
  keys = {
    {key="UpArrow", mods="SHIFT", action=wezterm.action{ScrollToPrompt=-1}},
    {key="DownArrow", mods="SHIFT", action=wezterm.action{ScrollToPrompt=1}},
    -- activate pane selection mode with the default alphabet (labels are "a", "s", "d", "f" and so on)
    {key="p", mods="SUPER", action=wezterm.action{PaneSelect={}}},
    -- show the pane selection mode, but have it swap the active and selected panes
    {key="0", mods="SUPER", action=wezterm.action{PaneSelect={mode="SwapWithActive"}}},
  },
  bold_brightens_ansi_colors = true,
  window_decorations = "RESIZE",
  window_close_confirmation = "NeverPrompt",
  pane_focus_follows_mouse = true,
  quote_dropped_files = "Posix",
  -- line_height = 1.05,
  -- hide_tab_bar_if_only_one_tab = true,
  scrollback_lines = 5000,
  -- use_ime = false,
  exit_behavior = "Close"
}

Expected Behavior

1. Copy any command from browser or elsewhere (echo "hello world" or "curl XX")
2. Paste it in terminal and press enter
3. Command is run

Logs

18:12:17.659 INFO wezterm_gui::termwindow > OpenGL initialized! Apple M1 Pro 4.1 Metal - 76.3 is_context_loss_possible=false wezterm version: 20220629-072326-e6efec82

Anything else?

No response

[wez]

Thanks; I think you're just seeing how your shell handles bracketed paste mode. I'm assuming that you're using zsh because you're on macOS.

By default, zle_bracketed_paste is enabled in zsh which causes zsh to ask wezterm to send pastes wrapped in an escape sequence that zsh can use to distinguish between the paste and keyboard input. zsh then puts it into the line editor as a highlighted chunk of text.

If your paste has newlines in it, those are treated as a multi-line input buffer in the zle rather than causing zle to automatically accept the input and evaluate it.

You can use unset zle_bracketed_paste to turn that behavior off if you prefer. If you're an Oh My Zsh user there may be other configuration options that you want to consider instead.

[raivivek]

If your paste has newlines in it, those are treated as a multi-line input buffer in the zle rather than causing zle to automatically accept the input and evaluate it.

if I understand this correctly, in the non-bracketed paste mode, if there's a newline in the copied text, then zle will evaluate it and run the command. But in my case, I am explicitly pressing "enter" key after pasting a command, but nothing happens. I'd imagine that in either mode, if I paste something and press enter, that should work? I am not too familiar with terminal-foo, so apologies for misunderstanding.

[wez]

In non-bracketed paste mode, there is not way for an application to distinguish between content that was pasted and content that was typed by the user, so if there is a newline then it will appear as though the user pressed enter.

I think you might have something configured in your shell that is responsible for the "enter" behavior you describe, as I cannot reproduce it; you can't really see it from this screen shot, but:

I copied the echo hello world line and the start of the next line and then pasted it, then hit enter and it ran the command.

[raivivek]

I see. Thanks I appreciate the additional information. I will keep the issue open for a day or two as I continue to test when/how I run into it and let you know how it goes? Alternatively, feel free to close it now and I'll request to reopen when I know more.

[vyvl]

Hello,

I am on macOS and facing the same issue after updating wezterm to the latest version (wezterm 20220624-141144-bd1b7c5d), this happens in both bash and fish. If I type any command or paste anything on terminal and press the Numpad enter key it is taken as Ctrl+C and cancels the entire line. If I press the normal enter key, it executes the command. In below screenshot the first echo command didn't run because I pressed Numpad enter key, the second one worked as I used enter key. Let me know if you need any more information or if it is unrelated to this issue.

I suspect op is using numpad enter key when they paste content and normal enter key when they edit and execute the pasted command, so this could be the same issue.

[raivivek]

@vyvl Thanks for pointing this out -- indeed, that seems to be the case which is why I was not able to consistently reproduce it since I was not paying attention to which Enter key I was using. Using the Enter key from numeric pad does not print anything but regular Enter key works.

[wez]

I don't have any macs with a keypad. Can you run: wezterm --config debug_key_events=true, press the keypad enter key, and share the logged info about the key press/release for me?

[vyvl]

My mac does not have a numpad too, I am using an external keyboard (MX Keys) connected to macos if that makes any difference.

Pressing normal enter key without typing anything creates a new prompt again but numkey enter does not change anything as shown below. Also attached the logged info (screenshot and text) after I pressed numkey enter. Please let me know if you need anymore info.

❯ wezterm --config debug_key_events=true
08:50:32.756  INFO   wezterm_gui::termwindow > OpenGL initialized! Apple M1 Pro 4.1 Metal - 76.3 is_context_loss_possible=false wezterm version: 20220624-141144-bd1b7c5d
08:50:34.811  INFO   wezterm_gui::termwindow::keyevent > key_event RawKeyEvent { key: Char('\r'), modifiers: NONE, phys_code: Some(KeypadEnter), raw_code: 76, repeat_count: 1, key_is_down: true, handled: Handled(false) }
08:50:34.811  INFO   wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Char('\u{3}'), modifiers: NONE, repeat_count: 1, key_is_down: true, raw: Some(RawKeyEvent { key: Char('\r'), modifiers: NONE, phys_code: Some(KeypadEnter), raw_code: 76, repeat_count: 1, key_is_down: true, handled: Handled(false) }) }
08:50:34.811  INFO   wezterm_gui::termwindow::keyevent > send to pane DOWN key=Char('\u{3}') mods=NONE
08:50:34.811  INFO   wezterm_term::terminalstate::keyboard > key_down: sending "\u{3}", Char('\u{3}') NONE
08:50:34.893  INFO   wezterm_gui::termwindow::keyevent     > key_event RawKeyEvent { key: Char('\r'), modifiers: NONE, phys_code: Some(KeypadEnter), raw_code: 76, repeat_count: 1, key_is_down: false, handled: Handled(false) }
08:50:34.893  INFO   wezterm_gui::termwindow::keyevent     > key_event KeyEvent { key: Char('\u{3}'), modifiers: NONE, repeat_count: 1, key_is_down: false, raw: Some(RawKeyEvent { key: Char('\r'), modifiers: NONE, phys_code: Some(KeypadEnter), raw_code: 76, repeat_count: 1, key_is_down: false, handled: Handled(false) }) }
08:50:34.893  INFO   wezterm_gui::termwindow::keyevent     > send to pane UP key=Char('\u{3}') mods=NONE

[wez]

Interesting! Seems to be a regression of the fix in https://github.com/wez/wezterm/issues/739

[wez]

I've pushed a speculative fix for this, please let me know how it works for you!

It typically takes about an hour before fixes are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

[vyvl]

Thank you, the issue is fixed in nightly 20220704-211225-67b96b9b for me

[wez]

Thanks for confirming!

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.