Ctrl+Arrow Key and Ctrl+Shift Selection no longer work on Windows

[sbatten]

• I am on the latest Hyper.app version
• I have searched the issues of this repo and believe that this is not a duplicate

• OS version and name: Windows 10 x64 1709
• Hyper.app version: 2.0.0

Issue

Using Ctrl + Arrow Keys on windows used to control movement as expected. Now it outputs characters. Combining this with shift should select the text but now does nothing.

[Tyriar]

ctrl+shift+arrows should work, a Hyper keybinding might be intercepting it?

[oujunhao]

I don't know if this helps, but Ctrl+Left inserts b and Ctrl+Right inserts f.

[Xapphire13]

@Tyriar, those commands (at least on my machine) control tab selection. I think @sbatten is referring to navigating through input text

[Tyriar]

@Xapphire13 yeah, my statement stands; Hyper is intercepting it so it's not being interpreted by the shell.

[lordspamalot]

Same problem here.

Using Hyper 2.0.0 and Windows 10 1709.

If i use the key combination "ctrl+left arrow" then a "b" is written and if i use the combination "ctrl+right arrow" a "f" is written.

This behavior also occurs when I execute the function via the menu (Edit > Move to > Prevoius/Next Word).

Adjusting the keyboard shortcuts didn't help either:

"editor:movePreviousWord": "ctrl+left",
"editor:moveNextWord": "ctrl+right",

or:

"editor:movePreviousWord": "alt+left",
"editor:moveNextWord": "alt+right",

[jnpwly]

For me, using Hyper 2.0.0 (stable), and no plugins, on Windows 10 Professional (x64) Version 1803 (build 17134.228), the key combinations [ALT]+[Left Arrow] and [ALT]+[Right Arrow] move backwards and forwards through the entered text. I would expect [CTRL]+[Left Arrow] and [CTRL]+[Right Arrow] to do this. But, as others have mentioned above, [CTRL]+[Left Arrow] writes out a b and [CTRL]+[Right Arrow] writes out an f.

[dslatkin]

Experiencing the same issue on the most recent version for Windows. Ctrl <- outputs b and Ctrl -> outputs f. I'm guessing b stands for back and f for forward, and at some point not getting interpreted before it hits the shell.

(edit) FYI this pull request seems to identify and possibly fix issue. It seems defaultPlatformKeyPath always points to the Darwin/Apple keymaps file by default.

[dslatkin]

Played around some more with this and have some more information for someone who might be able to look deeper into the issue. The pull request linked to in my previous comment attempts to "fix" the issue by breaking this function call (putting you into the catch block for the try-catch):

https://github.com/zeit/hyper/blob/6451ba7f85fe5b88268cf4e57da8a1a13f6046b7/app/config/import.js#L29

You can get the same effect by either:

1. Simply commenting out that line that breaks
2. Replace contents of app/keymaps/win32.json with an empty object {}
3. Replacing instances of ctrl with alt in that same file

Additionally in win32.json I tried playing around with a couple other commands and I don't see "editor:deletePreviousWord": "ctrl+backspace" or "editor:deleteNextWord": "ctrl+del" working at all, regardless if ctrl is replaced with alt. Windows keymaps are not reliable at all right now unfortunately.

[chabou]

Which shell do you use?

[dslatkin]

@chabou For me the work was done in the default Windows shell

[braders]

I am also experiencing this when using Hyper with Cmder (following the instructions here)

[jnpwly]

So, here's something weird...

As we know, there are issues with Windows keymaps.

But, when I start a Windows CMD shell in Hyper (with this in the config: shell: '', shellArgs: ['--login']), and then SSH into a Linux box, then the CTRL+Left and CTRL+Right, etc. combinations work correctly. Exit the SSH session, drop back to the Windown CMD shell, and CTRL+Left and CTRL+Right are once again borked.

Well, it seemed weird to me. Maybe it's totally explainable?

[SamuelFisher]

I've had a quick look and I think this is what's happening:

In app/keymaps/win32.json, editor:movePreviousWord is mapped to ctrl+left. This means that whenever ctrl+left is pressed, Hyper does not send the ctrl+left to the shell - instead it interprets it as the command editor:movePreviousWord. The way the editor:movePreviousWord is implemented is it sends \x1bb to the shell:

https://github.com/zeit/hyper/blob/0d82f983eb6b932ffd66563bd6e8153bf03e7398/app/commands.js#L77-L79
https://github.com/zeit/hyper/blob/0d82f983eb6b932ffd66563bd6e8153bf03e7398/lib/index.js#L70-L72

The problem is that PowerShell and CMD do not interpret this as "move to previous word" (but Bash does, hence why it works on Mac/Linux but not on Windows). If you use WSL Bash as your shell, this does work correctly and moves the cursor to the previous word.

Previous comments mentioned that replacing the windows key bindings JSON with {} fixes the issue. This is because it causes Hyper to stop recognising ctrl+left as a command, and instead passes it through directly to the shell - so PowerShell/CMD receives a ctrl+left and moves the cursor to the previous word as expected.

By removing the editor:movePreviousWord command I was able to see what the actual data for ctrl+left is: '\x1b\x5b\x31\x3b\x35\x44'. So changing:

store_.dispatch(sessionActions.sendSessionData(null, '\x1bb')); 

to;

store_.dispatch(sessionActions.sendSessionData(null, '\x1b\x5b\x31\x3b\x35\x44')); 

makes this work for PowerShell and CMD.

I think perhaps what is needed is some extra configuration files similar to the keymaps json that determines which control characters should be sent for each command, depending on the shell being used.

E.g. for bash:

{
  "editor:movePreviousWord": "\x1bb"
}

for PowerShell/CMD:

{
  "editor:movePreviousWord": "\x1b\x5b\x31\x3b\x35\x44"
}

However, an easy temporary fix for CMD/PowerShell users is to override the key bindings for the commands that don't work to ''. Edit -> Preferences - set keymaps to:

keymaps: {
  'editor:movePreviousWord': '',
  ...
},

This stops Hyper interpreting them as commands and instead sends them directly to the shell.

[staticfrost]

thanks @SamuelFisher savior!!!!

[tcgumus]

Adding this code:

keymaps: {
    'editor:movePreviousWord': '',
    'editor:moveNextWord': '',
  },

fixed for me.

[mikemaccana]

Confirmed above workaround works in Hyper 3 too.

note: Remove any default keymaps using Ctrl+arrows too

    // These default keymaps also need to be removed
    // "tab:next": ["ctrl+right"],
    // "tab:prev": ["ctrl+left"],