bug-bash
[Top][All Lists]
Advanced

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

Re: Bracketed paste mode breaks cooked mode's tab + backspace


From: Egmont Koblinger
Subject: Re: Bracketed paste mode breaks cooked mode's tab + backspace
Date: Tue, 30 Jan 2018 09:47:06 +0100

Hi Phi,

> This is not directly related to bash, it depend on the line discipline
> on the tty, I use  ^H as erase and got no problems with <backspace>.

For me the same bug occurs after "stty erase ^H" and pressing ^H, too.
I would be really surprised if the kernel's logic on backspacing over
tabs (which is a purely output issue) depended on the choice of erase
character (which is an input issue).

Not sure why you don't see this bug. (You have at least v4.4, and
started a new shell after enabling bracketed paste, is that right?)
One theoretical explanation could be that your kernel's tty driver is
slightly different and expects the leading ESC byte to also move the
cursor, resulting in 8 characters in total, making no difference in
the modulo 8 computation for the tabs. (I don't think this is the
explanation, though.)

Even without bracketed paste mode, the issue should be reproducible
with commands like:
    echo -ne '\e[1m'; cat
Obviously it's not bash's fault and there's nothing bash could or
should do with this one.

> gnome-term, xterm are ok with , <backspace> generate 0x8, terminator
> is confused is it doesn't use X resouces and then can't map 0x8 on
> <backspace>

gnome-terminal doesn't use X resources either. gnome-terminal and
terminator both use the same VTE widget for terminal emulation, and
both have a setting under profile prefs -> compatibility to specify
what Backspace and Delete do.

> Using <backspace> generate <del> 0x7f is a flaw since ages :)

Whether or not it is true (I'm not sure), it is irrelevant here :)


cheers,
egmont



reply via email to

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