-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ctrl+up/down don't scroll in zsh #181
Comments
Could this be a duplicate of #151? |
I don't think ctrl+up/down is routed to the mouse wheel handler so probably not. |
It does look related to #151 and keypad cursor modes. Check out the xterm.js code for handling the up and down cursor keys.
The application-mode check is done first, and does an early return. The test for the Ctrl key is effectively inside the "normal keypad mode" branch of the logic. This also means that in application cursor keypad mode, the up/down arrow keys are being sent as plain cursor keys, with no modifier. In regular Xterm, modifiers take precedence over keypad mode. |
Maybe fixed with #200, cant test it myself. |
Ctrl+up outputs |
Just installed zsh with and omz and can't reproduce it. I get the following on Ubuntu 14 with my laptop keyboard (same behavior/output for xterm and xterm.js-demo): Tested again with gnome-terminal - Shift+Ctrl+ArrowUp scrolled instead of printing an 'A'. Did you mean PageUp/Down or ArrowUp/Down? |
OMZ may change the behavior, because it defines additional key bindings which are not present in default
Design decision. Many terminal emulators and OSes "capture" some modified cursor key strokes and map them to scrolling or other navigation instead of passing them to the pty. This is analogous to the Ctrl-arrow scrolling behavior in xterm.js before #200. When comparing behavior for terminals, you need to check the key binding configuration. In gnome-terminal, look under Edit > Preferences > Shortcuts to see if a modified cursor key combination is mapped to a terminal action instead of being passed along to the PTY. Shift-Ctrl-Up and Shift-Ctrl-Down are bound to scrolling by default in gnome-terminal. |
ctrl+shift+(most things) seems to be ignored by xterm as they are the only keybindings in vscode that seem to work when the focus is on the integrated terminal. I'm thinking ctrl+shift+arrow should be handled by xterm.js, not the pty as @apjanke suggests. |
Still not clear, why ctrl+shift+page up/down outputs ;6A and 6B for you. Seems the browser engine triggers the wrong keycode. Can you check the keycodes for ctrl+shift+page up/down? Do you have some keymapping active on X11 level? |
var modifiers = ev.shiftKey << 0 | ev.altKey << 1 | ev.ctrlKey << 2 | ev.metaKey << 3;
// modifiers = 0b0101 = 5
...
result.key = '\x1b[1;' + (modifiers + 1) + 'D';
// result.key = '\x1b[1;6D'; I'm suggesting something like this: var modifiers = ev.shiftKey << 0 | ev.altKey << 1 | ev.ctrlKey << 2 | ev.metaKey << 3;
if (modifiers === 5) {
// handle any special keybindings like ctrl+shift+arrow/page up/down
// don't set result.key so it's not send to pty
return;
} |
How about making this customizable? |
Much easier to accomplish now that #186 is implemented |
The text was updated successfully, but these errors were encountered: