On 8/17/24 10:39 AM, Reuben Thomas wrote:> 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".
And the whole business of user-specified key bindings is to transform the first into the second. At some level, users have to know what the keys on their keyboard do, or be able to specify the behavior they expect when they press a particular key, otherwise they'll never be able to bind key sequences. So this is going to be something for users who know what the meta key (or whatever it's labeled -- what is it on your keyboard?) doesand want to specify key bindings using that in a particular way -- since they could always just use \e. So let's get on with figuring out how to
do it. > > 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?
That the meta key is a key that performs your definition of the meta function -- adding the escape prefix -- and that a key that does not do that cannot be called the meta 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'.
Maybe at some future point. I introduce new variables in a way that if a user does nothing to change their environment they get the same behavior. Then after some period I may shift the default. Sometimes that doesn't work. Remember the meltdown when I made bracketed-paste enabled by default, after introducing it as a settable variable in an earlier version? That suggests leaving it explicitly unset (-1) by default and honoring its value if the user sets it (0 or 1), falling back to the value of convert-meta as in previous versions if it's unset. I could also see setting the initial value to the value of convert-meta after the locale initialization code sets convert-meta, and again allowing users to modify it. That requires no changes to existing configurations and allows users to set force-meta-prefix to what they want. Users who set force-meta-prefix should be prepared to modify it if necessary if they change the value of convert-meta.> 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.
enable-meta-prefix? bind-meta-prefix? meta-means-meta-prefix? >> 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.)
Not yet; see above. > * 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.) This isn't backwards compatible if the key binding code pays attention to force-meta-prefix. > * 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.) OK. > * 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. Not backwards compatible; see above. Or am I missing your meaning here? >> 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.
See above. That's how it usually happens.
--
``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
