Handling of backspace/delete

[kennylevinsen]

After some testing, I have noticed that handling of backspace/delete in Stream does not seem to be perfect.

My terminal emulators generally support these 4 options for backspace and delete:

• CTRL-H - \x08
• ASCII DEL - \x7f
• ESCAPE - \x1b[3~
• TTY ERASE - becomes ASCII DEL

Many terminals only have settings to go from ASCII DEL to CTRL-H for compatibility reasons. This option makes Emacs sad, but is sometimes required. The escape sequence appears to be the only sequence resulting in forward-delete behaviour in my shell (Although it appears broken when I ssh through tmux). Neither the ASCII del char, nor the escape sequence is handled by pyte's streams. The del char never seems to raise any events, with the escape sequence raising a debug event.

I will most likely fork it later today to add DEL to control and escape and submit a pull request, unless I forget or someone else manage to do it before me.

UPDATE:
The issue lies with ASCII DEL (\x7f) being explicitly ignored. The forward delete thing is under another issue, and closed for now. As per a comment from @superbobry this was likely to fix Midnight Commander, but I believe that it might be due to incorrect handling. \x7f is just a whitespace rendition-wise, cursor-increment and all. It's only magic when it arrives on stdin from a terminal emulator, which it tends to do quite often.

[jonathanslenders]

Unless I'm mistaken, pyte does only process the stdout of processes, and you're responsible yourself to connect the terminal input to the application, and if an application was designed to run in a vt100 terminal, it will understand these escape characters.
Maybe, @superbobry can confirm?

[kennylevinsen]

Stream drops input if it is \x7f (should have been handled as backspace), fails in the argument parser for \x1b[3~ (Throws KeyError due to not expecting a tilde - I have opened case 26 for that).

I'm using the streams to handle terminal input. Apart from a few unhandled scenarios, such as this, streams handle this scenario very well. Handling fancy terminal input is otherwise a pain in the butt. But even if this scenario will not be officially supported, applications are allowed to output an \x7f on stdout, which would require pyte to read it, not dump it.

I will also have to process the output of child processes later on, but I have not found anything but pyte that seems to have nice handling of everything these wacko terminals decide to throw at it.

(So, to everyone helping pyte get along, thank you very much. You help maintain the fragments of my sanity that I have left, even if only for a bit)

[superbobry]

The solution I've posted in #26 should work for backspace as well.

[kennylevinsen]

Yes, local extension should work.

And just like that, I might make a pull request that adds the extra keys. \x7f is at least essential.

[superbobry]

pyte already handles "\x7f" in streams.py:235.

[kennylevinsen]

That line explicitly ignores it. It's not in the basic (streams.py:61), escape (streams.py:74), sharp (streams.py:85), or csi (streams.py:90) dicts, and explicitly ignored for draw, causing it to raise no events.

[superbobry]

Oh, silly me, you're right. IIRC, this was done because it improved the visual appearance of Midnight Commander, but I'm not completely sure.

Unfortunately, I don't have a way of checking this atm.

[kennylevinsen]

Hmm, I just tested it - It works just like a space. Cursor moves right, inserts an empty character with the current graphics mode.
But, it still does something, so ignoring it would not be so nice. It would feel neglected. But it cannot be handled like backspace, but rather as its own delete event.

Maybe the original issue was that it was attempted handled as backspace, causing a bad cursor move?

[kennylevinsen]

Reopening temporarily until that is figured out.

[superbobry]

What kind of default behaviour do you expect for the DEL event?

I think what we need here is a simple GUI terminal app, using pyte on the backend. Otherwise it's impossible to make sure that we don't break things.

[superbobry]

I've just tested the following in iTerm2, xterm and pyte (via webterm.py)

$ awk 'BEGIN{printf "foobar%c42\n", 127}'

iTerm2 produces foobar 42, while xterm and pyte both result in foobar42. I would rather stick with xterm on that, because iTerm doesn't pass "Cursor movement" vttest.

Please feel free to reopen if you think this behaviour is incorrect.