Ctrl+h produces <BS> in Neovim

[skeate]

Expected Behavior

In Neovim, enter insert mode and press ctrl+v ctrl+h. Output should be ^H.

Current Behavior

Output is <BS>

Context

This seems to be a regression, as the Arch binary version works as expected. I tried building qterminal & qtermwidget from source to see if I might be able to track down the problem myself, but curiously the problem still occurs when building tag 0.9.0.

Many people map <C-W> h to <C-H> for easier window navigation, so this probably will affect a number of people if it winds up in a release.

System Information

• Distribution & Version: Arch
• Kernel: 4.19.4
• Qt Version: 5
• liblxqt Version:
• Package version: qterminal-git, qtermwidget-git. also when built from source

[yan12125]

This behavior is changed in https://github.com/lxqt/qtermwidget/commit/b5da2e2dacf91da5aad720a81ab5606996586532 and it's the correct version. Maybe qtermwidget can have an option to use non-standard behavior like VTE to achieve compatibility with specific applications.

[skeate]

This is a bit beyond my depth, so apologies if this isn't relevant; just trying to relay some info that might be.

There was an old issue about this in the Neovim repo: https://github.com/neovim/neovim/issues/2048 Specifically with the recommendation to modify the terminfo: https://github.com/neovim/neovim/issues/2048#issuecomment-78045837

Also, that commit messages suggests the change is to behave like other terminals, but in gnome-terminal the expected behavior I mentioned is the actual behavior.

[yan12125]

Thanks for the thread! Maybe my interpretation is wrong about Ctrl-H.

That's a long thread and I need some time to read them all :)

Also, that commit messages suggests the change is to behave like other terminals, but in gnome-terminal the expected behavior I mentioned is the actual behavior.

I was trying to make qtermwidget to behave like xterm, which is the standard for terminals using TERM=xterm.

[yan12125]

After reading most comments in the long thread and some relevant discussions, I decide to add an option to allow qtermwidget to behave like gnome-terminal.

Notes to my self:

• Neovim reads from termios to decide which key should be <BS>: https://github.com/neovim/neovim/pull/5758. The value is exactly the the erase item in stty -a.
• ASCII DEL is 0x7f (127) and ASCII BS is 0x08 (the same as ^H)
• leonerd, the author of libtermkey said:

Ctrl-H is "ASCII backspace" but terminals ought to be sending ASCII DEL for the Backspace key instead. This may or maynot agree with what their terminfo file says, however, so it's all a huge mess.

IMO that's crazy, but seems there's no better option.

• Another workaround mentioned in a thread comment (https://github.com/neovim/neovim/issues/2048#issuecomment-98192906) proposed to use extended unicode CSI-introduced sequences. Its specification can be found at http://www.leonerd.org.uk/hacks/fixterms/. It's the best solution from a technical viewpoint. Howver, it looks like only programs utilizing libtermkey/libtickit accept them, so it can't be the default for qterminal.

[Screwtapello]

IMO that's crazy, but seems there's no better option.

As some added historical context I learned recently:

• The original VT100 had a key above Enter labelled backspace that sent ^H, and a nearby key labelled Delete that sent ^?
• The original VT200 had a key above Enter labelled ⌫ that sent ^? and a key labelled Remove, where Page Up is on a PC 101-key keyboard, that sent ESC [ 3 ~

So, if you're emulating a VT100, then backspace should be ^H, if you're emulating a VT200 or above (like xterm does) then backspace should be ^?. Either way, the terminal emulator should set stty erase to match whatever encoding it's chosen for the backspace key.

[huyiqun]

Facing the same problem in qterminal, curious to know if this will be fixed.

[yan12125]

Either way, the terminal emulator should set stty erase to match whatever encoding it's chosen for the backspace key.

Sounds reasonable. Needs to investigate how to achieve that from qtermwidget. Probably invoking ioctls after allocating ptys?

[gsantner]

Hello, is there any fix already available, or a plan to fix it?

I used many different terminal-emulator applications (and also the non-gui fallback shell) - and qterminal is the only terminal application which not works correctly in this regard.
Pressing backspace does something complete else then in any other emulator (moving cursor position upwards), and trying to edit text this way is a chore, as it does something else then removing a character.

Is there any chance for this to be fixed, so backspace works properly like everywhere else?

Just for comparision - 4 different terminal applications. As it was mentioned somewhere that there is an option""to simulate gnome-terminal behaviour"". Not sure about that, i.e. KDE's Qt based konsole also does it right and that out of the box.

Versions tried: 0.17.0, 0.16.1

[ssb22]

Emacs users are also affected, since Ctrl-H is the default shortcut key for accessing Emacs's help system—otherwise you have to use e.g. M-x describe-function instead of Ctrl-H f. (My desktop Emacs runs on X11, but I also use it from the terminal when connecting to another machine over SSH.)

In QTerminal 1.4.0, Ctl-H works properly for me if I set File - Preferences - Behavior - Emulation to linux instead of default.