Hello, I'm not sure if this is the right place to report, but there is
a problem with .inputrc, so I would like to report it to "msys2
mailing list" mentioned in the comment of .inputrc. Is this the "msys2
mailing list"? If there is another mailing list that is called "msys2
mailing list", I would appreciate it if you could point the mailing
list for me.
The problematic keybinding is the following line (.inputrc L79):
"\C-?": backward-kill-line # Ctrl-BackSpace
(1) It's usually ineffective---this keybinding is usually overwritten
by the readline just before Bash shows the prompt, so is normally
ineffective. One can confirm this by putting the following line at
the end of .bashrc:
# At the end of ~/.bashrc
bind -p | grep '"\\C-?"'
and start the Bash session, and input and run the same command (bind
-p | grep '"\\C-?"') again. The result will be
"\C-?": backward-kill-line
$ bind -p | grep '"\\C-?"'
"\C-?": backward-delete-char
The first line shows the settings at the time point running .bashrc,
and the third line shows the setting after Bash started to prompt user
commands. You can see that the keybinding "backward-kill-line" set up
by .inputrc is overwritten by "backward-delete-char" while the
initialization process of Bash itself.
(2) It causes unintended behavior---The comment says
Control-BackSpace, but it actually binds to BackSpace. When it becomes
effective, it results in unintuitive behavior, which confuses users.
For example, one can make it effective by reloading .inputrc by
pressing "\C-x\C-r" [i.e., press Control+x and then Control+r]. Then,
Backspace (without Control modifier) starts to delete everything
before the current cursor position. It is clear from the comment ("#
Ctrl-BackSpace") that the intent of this keybinding is to change the
behavior of Ctrl-BackSpace, so the actual effect that changes the
behavior of Backspace is unintended.
# To explain the background in more detail, actually, the escape
# sequences of Backspace and Ctrl-Backspace depend on the terminal.
# But, in modern terminal emulators, "\C-?" is definitely the escape
# sequence of "Backspace" / "DEL" (without Ctrl modifier) but not the
# escape sequence of "Ctrl-BackSpace". Only some of the very old
# terminals send "\C-h" for Backspace and "\C-?" for Ctrl-Backspace.
# Modern terminal emulators typically send "\C-?" for Backspace and
# "\C-_" for Ctrl-Backspace. Some send "\C-?" for Backspace and "\C-h"
# for Ctrl-Backspace. Some minor terminals such as Windows Terminal
# seem to send "\C-?" for Backspace and "\C-w" for Ctrl-Backspace. For
# this historical variations, Bash/Readline actually tries to
# overwrite the settings based on the current TERM environment
# variable using the termcap/terminfo database, which is the reason
# why the keybinding is ineffective by default.
#
# This keybinding caused a real problem with a Bash setting ble.sh
# reported at https://github.com/akinomyoga/ble.sh/issues/104 . ble.sh
# is a replacement for Readline and don't overwrite the keybindings
# set by users. So, the keybinding became effective and caused the
# unintuitive behavior.
I'd recommend just removing this keybinding since it has been
ineffective and even no one seems to have noticed that until now.
Maybe it works in some old terminal used by the one who added this
keybinding, but such an environment-dependent setting broken in the
typical terminals should not enter the default .inputrc. If the
maintainers think this keybinding is really needed for the default
MSYS2 setting, I recommend switching the escape sequence from "\C-?"
to "\C-_". Maybe one can optionally add another keybinding "\C-h":
backward-kill-line, but this again causes a similar problem in some
terminals because "\C-h" is sometimes Backspace, so I don't think such
a keybinding should be set up by the default .inputrc.
Thank you,
Koichi
|
