Re: [Mutt] #2952: <BackSpace> should use terminal settings
#2952: <BackSpace> should use terminal settings
Comment (by Kyle Wheeler):
On Tuesday, September 11 at 04:42 PM, quoth Mutt:
>> essentially treating 'r' as my backspace key. Thus when I tell
>> mutt to bind "backspace" to something, I expect mutt to bind 'r' to
>> that something. It's simply consistent.
> However readline (as you cited it in one of your messages) doesn't
> work the way you want. For instance, if I create a .inputrc file
> Rubout: "foo"
> to bind backspace to the string "foo" and run "stty erase r", then
> start bash, I get "foo" when typing backspace, and the 'r' key still
> does the erase function.
Good point; it's even worse than that. Rubout in readline (in my
xterm) maps to ^? (which, interestingly, is what I've configured my
backspace key to emit), while <BackSpace> in mutt (in my xterm) maps
You're correct that readline is defining the configuration keyword
RUBOUT statically rather than detecting it dynamically, which I view
as wrong, but bizarrely, readline is somehow detecting it to be
different than how mutt is detecting it. So, readline would appear to
be a bad example.
Upon further examination, I find readline interestingly inconsistent.
Your readline still performs a backward-delete-char if you've used
stty to set r as the erase character. In my terminal, readline seems
choosy about whether it's going to respect the erase character or not.
For example, if I set ^R to be the erase character, readline refuses
to obey: ^R still triggers reverse-search-history. And if I set r to
be the erase character, typing r still inserts an r. But using stty to
switch between the usual suspects (^H and ^?), readline will happily
trigger backward-delete-char for whichever one I've set as the erase
character, with no change to my ~/.inputrc.
Ticket URL: <http://dev.mutt.org/trac/ticket/2952#comment:>