If the `convert-meta' option is turned on, the key sequence produced by rl_invoking_keyseqs_in_map will use `\M-' to represent any non-terminal instances of ESC in the key sequence. This results in output that isn't correct when there are consecutive non-terminal ESC's in the sequence.
$ LC_ALL=C INPUTRC=/dev/null bash --norc $ (bind -u undo; bind '"\e\eZ": undo'; bind -p) | grep -a ' undo' "\M-\M-Z": undo Since multiple `M-' prefixes will be merged, the above will not work as input, but it should be safe to just print `\e' instead, like the macro dumping code does for the same key sequence. $ (bind '"\e\eZ": ""'; bind -s) "\e\eZ": "" If the `convert-meta' option is turned off when a key sequence is bound, any non-terminal bytes of the sequence that have the 8th bit set will be printed literally. This is cosmetic since, unlike the above case, using the output as input will correctly recreate the original state (though copying from this message will not work). $ LC_ALL=C.UTF-8 INPUTRC=/dev/null bash --norc $ (bind -u undo; bind '"ππ": undo'; bind -p) | grep -a ' undo' "π�\200": undo Same sequence printed by the macro dumper -- we don't get the non-ASCII characters but overall seems more intelligible than the above: $ (bind '"ππ": ""'; bind -s) "\317\200\317\200": "" I don't think either representation is really a bug, though the differing and intermixed formats are somewhat confusing and make very difficult any programmatic introspection of the current binding state.
