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
_______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
