On Thu, 15 Aug 2024 at 19:53, Chet Ramey <chet.ra...@case.edu> wrote:
> > 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 :-)) > Filing mutually contradictory bug reports sounds like exactly the sort of thing I would do, but this one says "Tim Waugh" on it, and I don't see my name anywhere. Why do you think \M- should not obey convert-meta? That's why it's there. > I don't really understand the what "\M- obeying convert-meta" means. As far as I can see, `convert-meta` is nothing to do with keybindings, but about character encodings. 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?" > I think "locale's character encoding can include bytes with the eighth bit set" might be clearer, as that retains the point that the eighth bit is the top bit of something (as opposed to some random bit in, say, a 32-bit character). > 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. > I think you're saying that the Option key isn't necessarily configured to be Meta, which is not the same thing as saying that the Meta key doesn't always generate Escape. Isn't `obvious' in the eye of the beholder? More often than not, it means > `what I am used to'. > Well, I started using readline around 1992, and I filed the bug report in 2006, so what I am much more used to is the current situation. However, I think the current situation is unnecessarily confusing. Here's my attempt at a 2024 context: - Most users now are using UTF-8 locales, or other wide-character locales. 8-bit is a thing mostly of the past, never mind 7-bit. Few users these days know or care about bit counts in terminal protocols. - We're discussing key bindings in .inputrc. Most readline users' familiarity with binding keys will be with text editor key bindings. - readline explicitly aims to be similar in particular to Emacs and Vim. - Even in Emacs, on which readline is modelled, even when running in the terminal, one doesn't have to write keybindings in different ways depending on the terminal setup. In short, even an Emacs user is likely to find the current situation baffling. And readline should be (and largely is) entirely familiar to Emacs users, because it is designed to be! Users for whom Emacs is a bit of archaic arcana will already be confused by "Meta" ("my keyboard has no Meta key, WTF"), and adding another distinction based on the terminal setup and which keys one is binding only makes that worse. Such users will probably give up altogether. I think that's a shame, because readline is available on most systems, even today, is used by many programs, and is easy (via rlwrap) to add to many more. It could be serving many more users than it likely does. 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? > I'm sorry, I don't know what it means under the hood. I am saying that when I write in my .inputrc: "\M-p": history-search-backward That should bind Meta+P on my keyboard to history-search-backward in readline, just as when I write (define-key minibuffer-local-completion-map "\M-p" 'previous-complete-history-element) in my .emacs, that binds Meta+P on my keyboard to previous-complete-history-element in the Emacs minibuffer. Emacs manages to work out how to implement this, whether it's using X11 keyboard events, terminal key codes, or whatever happens on Windows or macOS. ``Ars longa, vita brevis'' - Hippocrates > I'll raise you "Ars est celare artem"! -- https://rrt.sc3d.org
