feat: separate handling of Control-H (^H) and Backspace

[eugenesvk]

Allows achieving the console usability level of Windows :), where ^H and BS are already handled separately, e.g. with this patch you can bind backward-kill-word to Control-Backspace (which usually emits ^H) while leaving Backspace backward-delete-char

Per this comment this would be a breaking change, though a worthwile one

Closes the second part of #1380

[jonathanslenders]

Thanks. This sounds fine. If you have time, can you have a look at why the tests are failing? Otherwise I'll have a look later on.

[eugenesvk]

Hey, I've already looked into it — please check this comment in the original issue #1380 (comment)
Basically, we need to either remove the two tests or add the code to make the new keybind behave the same way as before the separation

I see that there are two items in the test_cli.py failing, so if we don't want to add handle("c-h", filter=insert_mode)(get_by_name("backward-kill-word")) to emacs.py to make them pass I guess those need to be removed as Esc+^H wouldn't be expected to backward-kill-word like Esc+BS does?

Personally I'd prefer to add the keybinds so that ^H kills a word everywhere (and that's what I'm doing in my xonsh configs), this would make the tests passing, but I

... left the non-Windows ^H bound to backward-delete-char, not to backward-kill-word as I'm not sure if it'd break anything there

and need someone more knowledgeable about the use cases of ptk to make that call

[jonathanslenders]

I'm trying the behavior in different terminals.
Putty seems to have a setting where backspace always sends ^H.

This means, that users with this setting enabled, won't be able to use backspace as usual if we bind ^H to backward-kill-word.

[jonathanslenders]

What I'm also afraid of is that some users have the habit of literally typing control-h instead of backspace when they're in a terminal, because the key is easier to reach. So, I'm not sure we should make it a default on Linux. I'm still not sure.

[eugenesvk]

I'm trying the behavior in different terminals.
Putty seems to have a setting where backspace always sends ^H.

But the default in putty is the second one, so it's not an issue?

Otherwise yeah, many terminals have only two codes (8/0x08 and 127/0x7f) for these three keys/combos
ControlH
ControlBackspace
Backspace
so whatever you set you won't get the full separation, need a terminal that supports a third key code 31/0x1f

What I'm also afraid of is that some users have the habit of literally typing control-h instead of backspace when they're in a terminal, because the key is easier to reach. So, I'm not sure we should make it a default on Linux. I'm still not sure.

Interesting that a two-hand/two-key combo is easier to reach than a one-hand/one-key BS, but whatever moves your fingers ;)
But yeah, I totally get that there isn't really "the ideal" option as some uses cases are mutually exclusive, I guess the default should reflect what's expected by most of your users (if anyone knows what that is :))

[jonathanslenders]

Interesting that a two-hand/two-key combo is easier to reach than a one-hand/one-key BS, but whatever moves your fingers ;)

I'm personally using a pok3r keyboard where the arrow keys are under FN+jkli (where my fn is on caps lock). It's not unusual either to use ctrl-h as backspace.

[eugenesvk]

I'm personally using a pok3r keyboard where the arrow keys are under FN+jkli (where my fn is on caps lock). It's not unusual either to use ctrl-h as backspace.

Oh, great minds think alike :), I have exactly the same cursor bindings (also with a caps lock), though that serves as a supplemental cursor as I still like the dedicated one; and caps lock+h would make perfect sense in this setup, but ctrl-H is still a bit strange

[eshepelyuk]

Is there any progress on this ?

[roachsinai]

Any updates? Thanks!