On Fri, 16 Aug 2024 at 19:37, Chet Ramey <chet.ra...@case.edu> wrote:
> > OK, so it's a key on the keyboard that performs a particular function: to > compose with another character/keypress and send ESC before that other key, > as if you had pressed the ESC key and this other key separately. Let's use > that as the basis for something new. > I think it is important to maintain the distinction between the key binding (the user holds down some key marked or otherwise designated Meta, then presses and releases another non-modifier key, then releases the Meta key) and what this does in terms of the terminal (here, sends ESC followed by the code generated by the non-modifier key). Most users will only care about the key binding, and it's that notion I'm trying to capture here; indeed, this issue arose exactly because the focus of readline is on what happens under the hood, not on what the user does. This is important because it affects the meaning of a keybinding in .inputrc: a user will, I am suggesting, expect it to mean "run this command when I perform these key presses", whereas readline understands it as "run this command when these key codes are sent". > Sure, but you're making the base assumption here about the behavior of > pressing the meta key. > Sorry, I'm not clear what assumption I'm making, other than Meta being a modifier key? OK, then let's figure out the new behavior. It will obviously require a new > settable readline variable, name to be determined (maybe something like > `force-meta-prefix' or similar). If this variable is set, Meta-C and "\M-C" > in key bindings act as if convert-meta were on and actually bind "\eC". If > it's unset, the key binding code behaves as if convert-meta were unset in > the current readline release. > I agree that a settable readline variable is what's required. I'm also daring to suggest that it should be on by default at least in wide-character locales; or more simply, it should default to 'on' exactly when convert-meta defaults to 'off'. I don't like the name `force-meta-prefix`, because it describes what the setting does under the hood rather than the user-visible behaviour it specifies, but it's consistent with the names of other settings, and I don't have a better idea. The specification of what it does looks right to me, at least in the default case. What happens when the user configures various other values, though? - force-meta-prefix is (default) on, convert-meta is (default in ≥8-bit locale) off: all good! (This in particular is what I'm trying to achieve.) - In a 7-bit locale, force-meta-prefix is (default) off, convert-meta is (default) on: all good! (We haven't messed up this default.) - In a ≥8-bit locale, when force-meta-prefix is set to off: we get the current behaviour: good. - If convert-meta is set to on, force-meta-prefix will have no effect, so the current behaviour will be obtained: good. (Existing configurations that set convert-meta to on will work as they did before.) - If convert-meta is set to off in a 7-bit locale, since force-meta-prefix will already be off by default, you'll get the same behaviour as before: good. The other combinations involve changing both variables; I don't think it matters so much what happens then, as these can't by definition conflict with previous behaviour. > Should it be ignored if the user has not set it explicitly, so the behavior > is backwards compatible? > This may be unavoidable, but it would be sad, because it would then only help users who set it, whereas what I'm trying to do is make readline behave more usefully and comprehensibly for users who've never heard of ISO-8859-1 or ASCII. In that case, maybe it could be slated to be switched at some future point like readline 9 and bash 6. Breaking backwards compatibility is painful, but if we never break it, we make it increasingly likely that that part of the stack will be replaced; we hope to have far more users in the future than we have in the past, and therefore it is perhaps reasonable to make a well-documented break, with an option that existing users can set to preserve the current behaviour, rather than never change the defaults. -- https://rrt.sc3d.org
