bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chet Ramey
Subject: Re: [Bug-readline] Control-O keybinding does not work [with patch]
Date: Thu, 18 Jan 2018 11:25:27 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 1/18/18 10:41 AM, Rhialto wrote:
> On Thu 18 Jan 2018 at 07:42:51 -0500, Chet Ramey wrote:
>> OK. The logical conclusion of your argument is that readline should disable
>> all tty special characters because there is a possibility that a user or
>> an application will add a binding for them, even though readline doesn't
>> use that binding itself.
> 
> or... (see below)
> 
>> What is reasonable is to expect an application (or a user) to make sure the
>> key sequence it wants to use is available in those cases where readline
>> doesn't use it.
> 
> So, according to this reasoning, to use the reverse-i-search (^R)
> functionality, the user should "stty rprnt disable". And to use
> transpose-chars (^T) the user should "stty status disable". And, to go a
> bit further, to use unix-line-discard (^U) the user should "stty kill
> disable", because unix-line-discard additionally features "The killed
> text is saved on the kill-ring." and termios doesn't.

No, you've missed the point. 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.

> In other words, what you say already isn't so, and the user doesn't
> expect it to be so, (probably) because readline offers sufficient
> additional functionality that the difference with a normal termios input
> is clear.

Don't be disingenuous.

> Readline already disables (or handles in some other magic way) lots of
> other special characters because they interfere with the line editing
> that it offers. It just has overlooked ^O.  In some places. In others it
> is already properly included, such as save_tty_chars().

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

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

-- 
``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/

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]