Incorrect Handling of Arrow Keys in miniterm.py

[GHPS]

I stumpled upon this bug when tracing down a problem in mpfshell - a shell for micropython [1].
There the problem came up that the arrrow keys show a lagging behaviour when navigating the shell history or the command line.
Basically you press ARROW-UP, nothing happens, you press ARROW-UP again and get the arrow-up functionality once [2]. This, of course, renders the REPL of micropython pretty useless...

To find out what is received and sent by miniterm I added two lines of debugging code:

diff miniterm-backup.py miniterm.py
168a169
>             print("[def getkey] key list: ",list(c))
493a495
>                     print("[def writer] transformed: ",list(text), " encoded: ",list(self.tx_encoder.encode(text)))

This made clear that there is at least a bug in the getkey function (and probably in the encoding function)..

After the first keypress you get

[def getkey] key list:  ['\x1b']
[def writer] transformed:  ['\x1b']  encoded:  [27]

After the next single keypress you get

[def getkey] key list:  ['[']
[def writer] transformed:  ['[']  encoded:  [91]
[def getkey] key list:  ['A']
[def writer] transformed:  ['A']  encoded:  [65]
[def getkey] key list:  ['\x1b']
[def writer] transformed:  ['\x1b']  encoded:  [27]

Here getkey keeps kind of lagging behind. And I'm not sure about the correctness of the encoding...

The problem seems to be limited to Linux and Python 3.x. I've done the testing with Kubuntu 16.04-64,
Python 3.5.2 and pyserial 3.2.1.

GHPS

---

[1] https://github.com/wendlers/mpfshell
[2] wendlers/mpfshell#11

[cefn]

I can confirm this experience on Lubuntu Trusty with the latest pyserial and miniterm available from pip also when accessing the Micropython REPL, by invoking...

python -m serial.tools.miniterm --raw /dev/ttyUSB0 115200

A character appears to be swallowed, which massively confuses the logic of the REPL (when using the up-arrow-history to retrieve a command, it executes the neighbouring line, not the one shown).

The same REPL interface is functional without errors when invoking screen like...

screen /dev/ttyUSB0 115200

[cefn]

In debug mode, invoked on my machine by...

python -m serial.tools.miniterm --filter debug --raw /dev/ttyUSB0 115200

I noted that the first time you begin to press the arrow key it appears to generate just...

[TX:u'\x1b']

...while subsequent times, pressing the arrow key generates the following three events...

[TX:u'['] [TX:u'A'] [TX:u'\x1b']

Don't know if this is relevant somehow.

I am running within LXTerm where env reports TERM=xterm , LANG=en_US.UTF-8 and SHELL=/bin/bash

[hoihu]

I can confirm this on OSX 10.11.6 using python3.5.1 and pyserial3.2.1

[cefn]

I can confirm from my testing that the new version has removed the problem for OS X, (and probably similar terminal environments such as an Ubuntu xterm session) such that the following invocation on my machine creates a fully-functional interactive terminal session over serial with a NodeMCUv2 running Micropython 1.8.6 ...

python miniterm.py --raw /dev/tty.SLAB_USBtoUART 115200

[GHPS]

Great - the new version fixes the bug.

According to my own testing it initially was a problem between the blocking select.select statement and incremental decoding of the input stream. The select statement blocked before all decoding was done.

But that is history now...