Closed Tyriar closed 6 years ago
parisk
commented
8 years ago I am 👍 on this. I think one good thing we could do is create an API which is compatible with the inputrc format: http://www.securitronlinux.com/mint_linux/using-the-inputrc-file-to-control-keybindings-in-xterm/.
This could provide great experience with the user's customization's available out-of-the-box, when xterm.js is wrapped in native applications like vscode.
Tyriar
commented
8 years ago Yeah I need to check out what's in my .inputrc and what if anything is done via gnome-terminal-specific settings.
ayapi
commented
7 years ago hmmm...? Xterm reads .inputrc? from my understanding, .inputrc is for Readline, not related to Xterm.
i thought .Xresources ( XTerm.VT100.translations: #override ) is suitable for this issue.
like this -> http://unix.stackexchange.com/questions/138501/keybinding-in-xterm-to-shift-one-line-up-using-shiftup
parisk
commented
7 years ago It was just a proposal to understand the syntax. X resources seems more suitable though.
Tyriar
commented
6 years ago I'm closing this off to keep out issue count lower as it hasn't gained any traction, is stale or is not worth tracking.
Alex-duzhichao
commented
1 year ago @Tyriar Hi, should this problem be fixed? I'm using vim with mapped Alt+Arrow keys to jump to different panes. It does work with other terminals (powershell, alacrity...), but doesn't work with xterm.js
The command showkey -a shows xterm.js sends different codes with other terminals':
| alacrity | xterm.js | |
|---|---|---|
| alt - up | ^[[1;3A | ^[[1;5A |
| alt - down | ^[[1;3B | ^[[1;5B |
| alt - left | ^[[1;3D | ^[[1;5D |
| alt - right | ^[[1;3C | ^[[1;5C |
jerch
commented
1 year ago I dont quite get the idea behind those "// HACK: Make Alt + left-arrow behave like Ctrl + left-arrow:" changes in Keyboard.ts. By what were these hacks justified? Why would anyone want Alt+Arrow to behave exactly like Ctrl+Arrow?
Tyriar
commented
1 year ago @jerch it might have been me making things act as I would have expected when I was a noob. If so these should probably be in vscode's keybindings instead
Tyriar
commented
1 year ago jerch
commented
1 year ago @Tyriar Ah no worries, was just trying to get the idea behind that change, and I was not able to find the reason in the old issues/commits. Because if there is a good reason, we prolly cannot simply change it to something else.
4538
:+1: To make it somehow configurable is prolly the best idea. Hopefully thats not too tricky, I always get the impression, that the key handling code is full of pitfalls and fixing one thing will break 2 others :sweat_smile:
Tyriar
commented
1 year ago The custom keybindings request in xterm.js was eventually closed as embedders can set it up to do whatever they want. My philosophy since then has been do baseline behavior in xterm.js and anything non-standard in embedders where you can probably configure as a user.
Some built-in examples in vscode that try make the terminal act more like the editor:
As per https://github.com/sourcelair/xterm.js/issues/239#issuecomment-242633928 I think things like alt+arrow to jump words should be able to be turned off (or be off by default).
It does make sense for this stuff to be integrated into xterm.js so it works as most people would expect out of the box. However, in vscode for example, I would prefer if alt+arrow for example was routed to vscode's keybinding system so that users can define their own keybindings for this. In other words, I would like to turn this off and have vscode call into a public API to send the "Jump over word left/right" key sequence.