On 8/16/24 6:40 AM, Reuben Thomas wrote:
On Thu, 15 Aug 2024 at 19:53, Chet Ramey <chet.ra...@case.edu
<mailto: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
<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.
I don't know that they're mutually contradictory. If you look at Tim's bug report, you see a link to the bugzilla report he's forwarding, and that's from you. It's a report that Meta-p and "\M-p" behave differently when used to bind key sequences, and your complaint now is that I chose the behavior you don't prefer then.
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.
If you're going to have readline convert a character with the eighth bit set to a meta-prefixed sequence on input, why not have the key binding you specify reflect that? That was the original complaint. If you're going to have meta-p (however you enter it on your keyboard) actually emit esc-p, you want the keybinding for \M-p to actually bind esc-p -- that's the whole reason for your bug report -- and convert-meta is the way to specify that.
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).
OK, that's clear.
> 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.
What I'm saying is that on macOS, the option key is the meta key, in that it can be configured to either send meta characters (option-p emits "π", for example) or be used as a meta key in the way you mean it with the escape meta-prefix. I think it's just a terminology difference. If you think meta means to unconditionally send the meta-prefix (escape), that's fine, but is that the same as the `meta character' (characters with the eighth bit set) that convert-meta refers to?
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.
Sure. I mostly meant your aside reference to "like Emacs".
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.
Yep, agreed. But you'd be surprised at how many people force us-ascii for one reason or another.
* 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.
Emacs, yes, to an extent. vim, no. It's vi editing as specified by POSIX. There are plenty of vim extensions readline eschews.
* 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.
How does it do that? Or does it simply default to the equivalent of setting convert-meta to on, whatever it is?
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.
But readline doesn't use `meta' in the way you mean. It's always consistently used meta as referring to a character with the eighth bit set. Look at the `input-meta' and `output-meta' variables. You might not think that such a distinction has value in today's world, but let's at least use the terminology readline has traditionally used.
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-backwardThat should bind Meta+P on my keyboard to history-search-backward in readline,
So you want the \M- portion of the key sequence to reflect what the meta key on your keyboard does (whichever one that is, since lots of keyboards on windows laptops, for instance, don't have a meta key, either), without telling readline explicitly. It's a new capability, basically defaulting convert-meta to on for key bindings while being careful not to strip the eighth bit from any multibyte characters (which I think we already do, to be clear). 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.
It's only the terminal key codes part of that I'm interested in. My guess
is that it performs the equivalent to having convert-meta on.
So why not try setting
set convert-meta on
in your .inputrc before any key bindings and see if that gets you where you
want? If there are no negative effects when entering multibyte characters
from the keyboard, we can talk about defaulting convert-meta to on in a
locale with UTF-8 encoding.
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
