Someone else already provided a suitable answer. Continuing this
conversation is not productive; it's quickly reaching dead horse
territory.
You might want to check out the latest devel branch snapshot, though.
It works! Thanks a lot.
Bug seems to be fixed in
Please stop mischaracterizing the issue. It's not a bug: it's a case of
konsole's mismatched expectations. Since the mechanism it uses is not
documented, and relies on something in readline that is not documented, it
can't fairly be called a bug.
Should long text line move when user changes
Askar Safin wrote:
Please stop mischaracterizing the issue. It's not a bug: it's a case of
konsole's mismatched expectations. Since the mechanism it uses is not
documented, and relies on something in readline that is not documented, it
can't fairly be called a bug.
Should long text line
No. You have missed the point. The point is that the secret mechanism
that konsole used to use no longer works. It didn't rely on documented
behavior; it relied on a side effect of the (flawed) readline-6.2
implementation. It can't really be called a bug.
Okey, so, Chet, what will you say
Doesn't seem like a bug to me. You asked your terminal emulator to clear
the screen. It did so. Now you complain that it's too clean :)
When I type Ctrl-L, screen clears, and prompt appears. Ctrl-Shift-X should work
the same and it should clear scrollback additionally.
bash 4.3 + konsole behavior
There are only a couple of ways to do this, so even though the mechanism
konsole uses is undocumented, we can try to figure it out. There are two
possibilities: inject a character into the input stream, or send a signal
to the foreground process group.
I tested this. This is not some symbol in
Also, is there somewhere some real revision control system with bash
sources? http://git.savannah.gnu.org/cgit/bash.git appears to be
incomplete: git bisect shows that the problem is in
http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961
, but
7 matches
Mail list logo
