Hyper: Selecting text via shift+directional key not working as expected (arrow-, home-, end-key)

[fallmake]

1. Write any text in shell
2. using shift+home key does nothing (expected: select text from current position to home position)
3. using shift+end key does nothing (expected: select text from current position to end of line)
4. using shift+left arrow marks text visually, but copy doesn't work with a selection made that way.

Selecting text via mouse looks different (selection color differs) and works.

Encountered with powershell.exe

Hyper a35f39f
Electron 1.4.15
win32 x64 10.0.14393

[MaxFrost]

To extend this, things like ctrl+shift+arrow don't work as they do elsewhere . Ctrl+Arrow is "move to end of current word", and if you hold shift, it should also select the word as it moves. This behavior is the same regardless if you're in Word, Commandprompt, or Powershell. I believe the same shortcuts are also available in Linux and OSX, with OSX using command instead of ctrl.

Hyper v. 1.3.1
Win 10 x64

[MatthiasWinkelmann]

Shells on Unix traditionally don't have a concept of 'selection', so I believe this is working as intended. It spans across domains of both shell (cursor position) and terminal application (selection) and is probably quite difficult to get right across OS and shells.

[kleinfreund]

The Ubuntu Terminal app does understand these keybindings quite well while Hyper doesn’t.

Roughly documenting the features:

• Ctrl←: Move caret to previous word boundary (this is afaik the index of the first letter of the word across most operating systems)
• Ctrl→: Move caret to next word boundary (the behavior on Windows being that the the caret position will be the index of the first letter of the following word while on Unix systems it’s the index of the following whitespace character)
• Shift←: Move selection to the previous character
• Shift→: Move selection to the next character

[emiljohnsen]

This is an issue on Windows, or, well, I think it is.

Ctrl+Directional/Home/End for moving the cursor,
Shift+Directional/Home/End for selecting text.

Could also be that this is better suited for a plugin? The cmd shell in windows has limited support for these as well, natively, but are sorely missed by me at least.

What caught me a bit off-guard is that this is the standard behaviour in editable HTML components (contenteditable, input, textarea etc.).

Also, this might not be the issue for it, but a few other unexpected behaviours:
CtrlBackspace print "w"
CtrlA highlights everything in view, e.g.

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\%USER%>My test command

Instead of just "My test command".

[simoncorry]

This still appears to be an issue on Windows.