bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

rl_invoking_keyseqs_in_map meta chars with convert-meta


From: Grisha Levit
Subject: rl_invoking_keyseqs_in_map meta chars with convert-meta
Date: Thu, 3 Aug 2023 17:23:01 -0400

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]