The background to this is a Debian bug report I filed in 2006: 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. Vincent Lefèvre found the following changelog entry for readline 5.1 that seems to explain it: m. Fixed a bug that caused "\M-x" style key bindings to not obey the > setting > of the `convert-meta' variable. > As well as the issue of allowing users to use "\M-x" style key bindings regardless of the `convert-meta` setting, various bits of related documentation about seem to be out of date or at least confusing: 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. 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? 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 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? -- https://rrt.sc3d.org
