On 2025-07-09 14:13:59 -0400, Chet Ramey wrote:
> On 7/9/25 12:21 PM, Vincent Lefevre wrote:
> > On 2025-07-09 11:40:17 -0400, Chet Ramey wrote:
> > > On 7/9/25 10:56 AM, Vincent Lefevre wrote:
> > > > A \C-u setting in the .inputrc file such as
> > > > 
> > > >     "\C-u": kill-whole-line
> > > > 
> > > > is ignored if ^U is the kill character (usual tty settings).
> > > 
> > > This is controlled by the readline variable `bind-tty-special-chars',
> > > which is enabled by default. It's been that way since bash-3.1, which
> > > was released in 2005.
> > 
> > So, this should be the equivalent of the kill character, i.e.
> > "erase the current line", which corresponds to kill-whole-line
> > ("Kill all characters on the current line, no matter where
> > point is"), but this is not what I get.
> 
> It isn't, though. The readline equivalent of the stty VKILL character
> is `unix-line-discard', which kills characters between point and the
> beginning of the line. (That happens to be the default binding for ^U
> in both emacs and vi modes).

The intent of the KILL character ("kill" in stty) is to erase the
line, as clearly documented in the stty(1) man page: 

       kill CHAR
              CHAR will erase the current line

(otherwise it should have said "erase the characters (backward) up
to the beginning of the line").

> This is what ^U does in (standalone) vi insert mode. Emacs does something
> different with ^U, of course. Since you can't move around the line in
> canonical Unix tty input, you're always at the end of the line and there's
> no difference in the effect of the two behaviors.

If you mean that there is an ambiguity between both, then

  bind-tty-special-chars (On)
    If set to On (the default), readline attempts to bind the control
    characters   treated specially by the kernel's terminal driver to
    their readline equivalents.

makes no sense for the KILL character as there would be 2 possible
readline equivalents, and this cannot be deduced from the above
description (the only way to disambiguate would be to take the
stty(1) man page into account, but the readline behavior does not
match the stty description, as I've said above).

Moreover, the above documentation is incomplete as it does not say
which has the precedence: the tty settings or the user's inputrc
file. And concerning the actual behavior, giving the precedence to
the tty settings as it does is a poor choice: if the user has some
specific setting in their inputrc file, the goal is to use it[*].
IMHO, when bind-tty-special-chars is On, the tty settings should
just have the precedence over the default bindings.

[*] In practice, there would probably be no differences, but for
the KILL character, there would be 2 variants: some users might
prefer unix-line-discard and others might prefer kill-whole-line.
That would be at least one reason why the inputrc file having the
precedence would be important.

Another point, in my stty settings, I have in particular:

  start = ^Q; stop = ^S

but though bind-tty-special-chars is On, this is ignored by bash
and readline (e.g. in gp), for which Ctrl-Q is quoted-insert and
Ctrl-S is forward-search-history, i.e. their default bindings.
This is fine for me, but does not behave as documented.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Reply via email to