On 8/14/24 5:50 AM, Reuben Thomas wrote:
The background to this is a Debian bug report I filed in 2006: https://
bugs.debian.org/cgi-bin/bugreport.cgi?bug=708979 <https://bugs.debian.org/
cgi-bin/bugreport.cgi?bug=708979>
With readline 5.0, one could have a keybinding such as the following
in .inputrc:
"\M-p": history-search-backward
Since readline 5.1 this hasn't worked; instead, one has to write:
"\en": history-search-forward
This seems to be the intended behaviour now, as far as I and other
contributors to the Debian bug could work out, but it's unfortunate.
OK. The original idea is that \M-n was supposed to model the meta key on,
for example, old Sun keyboards, where people used it to enter ISO8859-1
characters > 128. That's why the characters above 128 are, for the most
part, bound to self-insert.
Up until about bash-1.04, readline didn't do anything special with
characters with the eighth bit set, but you had to bind them yourself.
Between bash-1.04 and about bash-1.13, readline auto-converted characters
with the eighth bit set to escape-prefixed characters in both dispatch
and key bindings. There was no way to modify this behavior. I don't know
exactly why we did this.
As part of the effort to make readline 8-bit clean, I added an internal
variable to control this behavior, set to enable it for backwards
compatibility, and added convert-meta for users to modify it. This was
back in mid-1993. This is where we started to try to honor convert-meta in
key bindings, but it was inconsistent and treated \M unconditionally as
specifying the meta-prefix, even if you had tried not to by unsetting
convert-meta.
In late 2004, people started complaining about readline being inconsistent
with how it handled key bindings containing "\M-" because more and more
people were back to wanting to enter and bind key sequences containing
characters with the eighth bit set:
https://lists.gnu.org/archive/html/bug-bash/2004-12/msg00123.html
(you filed the original Red Hat report :-))
and that's when I made the change so both Meta- and \M- honor convert-meta.
So yes, the change was intentional, and it happened between bash-3.0 and
bash-3.1.
As well as the issue of allowing users to use "\M-x" style key bindings
regardless of the `convert-meta` setting,
Why do you think \M- should not obey convert-meta? That's why it's there.
The documentation for `convert-meta` says:
The default is On, but readline will set it to Off if the locale
contains eight-bit characters.
I read this as meaning that in a UTF-8 locale, convert-meta would be On. It
is in fact Off. The phrase "contains eight-bit characters" could perhaps be
revised to "contains greater than seven-bit characters", to avoid the
implication that it refers to old-style 8-bit locales.
Sure, I can see that. Since UTF-8 encodes multibyte characters using bytes
with the eighth bit set, you don't want to convert those to escape
prefixes. How about "locale can include characters with the eighth bit
set?"
Secondly, the documentation for `enable-meta-key` says:
> When set to On, readline will try to enable any meta modifier key
> the terminal claims to support when it is called. On many termi‐
> nals, the meta key is used to send eight-bit characters.
Vincent commented: "This is wrong, nowadays, the Meta key generates an
Escape character." So I guess it needs updating?
Maybe? On my mac keyboards, for instance, the option key can be configured
to do the escape-prefixing, but it's not the default. Maybe it is on Linux
GUIs.
But the specific termcap/terminfo capability that this manipulates is this:
meta_off rmm mo turn off meta mode
meta_on smm mm turn on meta mode
(8th-bit on)
I don't know if it's possible to arrange for "\M-x" style keybindings to
work in the obvious way (as an Emacs user, I would say "like Emacs"!) in
Isn't `obvious' in the eye of the beholder? More often than not, it means
`what I am used to'.
all locales (in particular, in old 8-bit locales it would seem to be
necessary to set `convert-meta` to On), but it should be possible at least
for UTF-8 locales, I would hope?
You have the option to set it yourself. Are you saying that readline should
default convert-meta to on by default in a UTF-8 locale? Or that it should
unconditionally bind \M- sequences to the meta-prefix? How would that help
people who want to bind and enter key sequences containing multibyte
characters?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
