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

[Rhialto]

On Thu 18 Jan 2018 at 11:25:27 -0500, Chet Ramey wrote:
> No, you've missed the point.

Of course, after I sent my message I reread it and realised that I had
misinterpreted your argument.

>  The difference between those functions and
> ^O is that readline doesn't provide a binding for ^O. So readline doesn't
> do anything with ^O.
> 
> The application, in this case bash, provides the ^O binding, but bash
> doesn't disable the tty special character -- because it doesn't have a
> mechanism to do it. Maybe that's a bash limitation, but so far using
> stty to turn off the special character has sufficed.

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".

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.

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.

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)

Mixing partial termios handling and partial readline processing is
inconsistent to me. Readline already sets so many settings, it has
basically taken over, and leaving out one setting is inconsistent. The
only place were ALL of this should be handled, including ^O, is in
readline.

> Because ^O doesn't "interfere with the line editing it offers."

^O doesn't do much useful when a read(2) is pending anyway. I tried, and
every other one basically seems to do the same as a reprint. So there is
no real harm to disable it while readline is active. ^T does more useful
things (not much more, but more) and is also disabled/reinterpreted.

> > 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.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl      -- are condemned to reinvent it. Poorly.

signature.asc
Description: PGP signature