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: Rhialto
Subject: Re: [Bug-readline] Control-O keybinding does not work [with patch]
Date: Thu, 18 Jan 2018 16:41:39 +0100
User-agent: Mutt/1.7.2 (2016-11-26)

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.

Yet readline doesn't make the user do that, and still performs those
functions.

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.

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

> Readline binds most of the tty special characters to its own, mostly
> equivalent, bindings. Why should it touch a character for which it doesn't
> provide a replacement, removing functionality users have always been able
> to rely on? That's not reasonable.

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.

> Bash doesn't have any functions to change the tty settings persistently,
> so the easiest thing for a user to do is to use `stty' to disable the tty
> special character for ^O. That's what I do.

That has the additional disadvantage that then you also don't have
flush-output functionality in the programs started from that terminal.
I'd like to flush command output from time to time, and I'd like to have
^O as a mappable character in bash / readline too...

Maybe, to do this properly, we need an additional range of settings, so
that one person can bind ^O to operate-and-get-next in bash and that
another can bind it to a new kind of function such as
termios-flush-output and have its termios functionality enabled while
readline is active (and the same for all other termios-settable
characters). But that's not what I am proposing at this stage.

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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