I want to have a custom binding for \C-m in my ~/.inputrc. However, the moment I replace it I can no longer enter any commands. E.g.,
"\C-m": vi-forward-word
The problem seems to be that there exists a default binding
"\C-m": accept-line
That is not a problem in itself but it appears other programs (the terminal?) send ^M (Ctrl-m) to indicate a carriage return. In my setup I have urxvt but I also tried xterm, the behavior is the same (return no longer works once I add the "\C-m" vi-forward-word binding at the end of my inputrc).
Now I want this changed, I am willing to patch any program/library involved. My question is: where should I look for the relevant pieces? I checked the readline source code but could not find anything indicating that \C-m is reused internally. Similarly, I checked urxvt but I cannot find anything mapping a carriage return to \C-m in the code (which would be my best guess for what is happening to cause this behavior). Interestingly there is rxvt.7.pod containing
KP_Enter ^M ESC O M
and rxvt-unicode.termcap with
...:cr=^M:...
However, both files seem to be mainly documentation or at least not installed. My knowledge of terminfo files and their involvement in the overall terminal workings is somewhat limited. The same is true for the interaction between readline and the terminal (is readline invoked before urxvt, in my example?). So if anybody has a pointer as to where to look I would be grateful.
As an aside: the moment I add
"\r": accept-line
after the "\C-m" binding I get back the original behavior (that is, return works). If I add the line before "\C-m" return still does not work as expected.
Cheers!
deso
The
"\r","\C-m","C-M",^Mare all the same character: ASCII CR (carriage return), and normally carriage return is mapped to newline (ASCII LF line-feed). That behavior is assumed by readline, of course. An application using the readline library could in principle suppress the mapping, but there are very few things that you could do usefully with just your.inputrcfile and the shell.The line
is irrelevant here: it refers to the Enter key on the numeric keypad, not the Enter key on the main keyboard.