Re: [Bug-readline] Control-O keybinding does not work [with patch]

[Chet Ramey]

On 1/18/18 12:04 PM, Rhialto wrote:

> Ok, another argument then. You already say that bash has no mechanism to
> disable ^O. And rightly so. Bash uses readline (presumably) because it
> doesn't want to get bothered with tty handling, and it outsources it to
> readline. Which I find a very reasonable approach. The same would hold
> for other readline clients. Gdb is one, I noticed. Gdb can also use an
> inputrc file (which is readline functionality). If such an inputrc file
> would map ^O, it would not work (on systems where ^O actually is
> supported by termios). I would bet that the gdb people won't like to be
> told "oh, check the inputrc file, and if it contains a mapping for ^O,
> disable its termios meaning".

They wouldn't be. The inputrc is controlled by the user; the user can do
what he needs to make sure it works.

> I would say that applications which use readline use it to handle ALL
> terminal setting. They don't want to be bothered with internal
> exceptional cases.

Maybe. There's another school of thought that says readline should only
change what it uses.

> 
> Likewise the user. How do you justify telling the user "If you want to
> bind ^O, you must also do stty x y z, and that has negative side
> effects. But if you want to bind ^R, don't worry, we have already done
> that internally". That is inconsistent.

Only in the sense that you omit the explanation that readline overrides
tty special characters for things it binds, and leaves the ones it
doesn't use alone.

> 
> Or if bash would handle the ^O case for me (because it binds it by
> default), but gdb doesn't, that's inconsistent.
> 
> If the readline copy in bash gets fixed for ^O, but the shared readline
> library isn't, that's inconsistent. (that's basically a another wording
> for the previous paragraph)

The only way that would happen is if, say, a distribution chose to install
bash-4.4 but left readline at version 6.3. The readline shipped with bash
is identical to the standalone version.

>>> I'd be happy with a solution where readline specifically checks if there
>>> is a binding for ^O (or any other special character) and only in that
>>> case it is disabled via termios. I just thought I'd keep it simple and
>>> in line with what's already there for VLNEXT and VDSUSP.
>>
>> This is a reasonable approach, and doesn't require new functionality that
>> would allow an application to inform readline that it would like to
>> override an additional tty special character.
> 
> It would be better, but more work.

Not really, maybe two lines of code. It's kind of an abstraction violation,
though.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/

signature.asc
Description: OpenPGP digital signature