Zagg Slim Book iPad Pro keyboard arrows issue about blink HOT 7 OPEN

Thanks for your report! First one we had for the Zagg keyboard, I've been testing it also with the Apple's Bluetooth Keyboard and it was fine. In the end the keyboard code should be the same and it must be captured by the iOS's KeyCommands. I assume from your comment that it is actually sending codes, although wrong ones. Would you mind running a showkey -a on the remote machine to see what we are sending there?

I will also add a feature to config, to be able to check the keyboard presses as they get mapped on the Blink side.

Thanks!

from blink.

Please let me know if this is fixed on v0.916 :)

from blink.

I'm having this issue with the Apple keyboard on the iPad Pro 10.5". Smart key output (hitting right, down, left, then up arrow keys):
$ showkey -a

Press any keys - Ctrl-D will terminate this program

^[[C     27 0033 0x1b 
         91 0133 0x5b 
         67 0103 0x43 
^[[B     27 0033 0x1b 
         91 0133 0x5b 
         66 0102 0x42 
^[[D     27 0033 0x1b 
         91 0133 0x5b 
         68 0104 0x44 
^[[A     27 0033 0x1b 
         91 0133 0x5b 
         65 0101 0x41 

To reproduce:

• Connect via mosh to a remote system (mine is MacOS)
• vi a file
• Hit the arrow keys to navigate

Expected result:

• Cursor moves around the file

Actual result:

• Cursor doesn't move
• When I hit the left arrow key, vi displays an error: `E388: Couldn't find definition"

Notes:

• The arrows behave as expected on the bash command line (e.g. Hitting up arrow displays previous command) on the remote machine (connected via mosh).
• In screen, if I hit the key sequence to enable copy/scroll back mode, the arrow keys have no effect
• showkey above was run within a screen session that exhibits the arrow keys not working for copy/scrollback.
• Arrow keys work as expected in screen and vim on the same machines in Coda's Terminal (i.e. Prompt2).
• I'm running blink compiled from the master branch (commit a6257c4)

from blink.

The problem appears to have corrected itself (which probably means it's intermittent or possibly happens on a new connection). As of yesterday, arrow keys move the cursor around in screen, vim, and even vim running on a server ssh'd to in a screen session.

from blink.

Installed commit ae9d47a and the issue is back. I suspect it has more to do with me being disconnected and having to type "mosh servername" again than with installing a new version. I'll see if the issue goes away by itself tomorrow.

from blink.

Hmmmm.... does it happen to all of the terminals at the same time? Or only on the one that got disconnected? Next time it happens to you, would you mind to do a double tap and see if the issue is there too? Thinking this might be an issue with the "mode".

from blink.

I only had one terminal running. But, if I add a second terminal (command-T) in Blink, then mosh myserver, then screen -RD, the arrow keys work as expected in the second terminal (and, oddly, the first terminal disconnects from the server completely with the message "[remote power detached]".

To reproduce:

• Quit Blink (double-click Home, swipe up)
• Open Blink
• Connect to a mosh server: mosh myserver
• Run screen -RD
• Hit CTRL-A CTRL-[ to get into copy mode
• Hit the up-arrow

Expected result:

• Cursor moves up

Actual result:

• screen displays "copy mode aborted" and some extra characters (as though you'd hit esc)

Then, continue with a new terminal and arrow keys work as expected:

• Hit command-T to start a new terminal in Blink
• mosh myserver to connect to the same mosh server
• screen -RD to detach and reattach your screen session
• Hit CTRL-A CTRL-[ to get into copy mode
• Hit the up-arrow

Expected result:

• Cursor moves up

Actual result:

• Cursor moves up

Note: if you then swipe back to the previous terminal, Blink displays:

[remote power detached]

Mosh session finished!

blink>

(The server doesn't have any command to exit, unless mosh-server is doing it, which is always possible).

from blink.