1. Enable history search on up/down arrow by adding this to .inputrc: > "\e[A": history-search-backward > "\e[B": history-search-forward See here: https://wiki.archlinux.org/index.php/Bash#History_completion 2. Start a new konsole session, and enter a long command (one long enough to wrap to the next line within the konsole), and run it 3. Enter the first few characters of the previous command and press the "up" arrow. Readline should complete the command for you. This used to work correctly, but in recent versions of Konsole, the result is visually messed up. The command still works if you try running it (despite looking garbled), but editing it is tricky. There is some mismatch between what letters konsole thinks is on the edit line and what is displayed.
Correction: even without history-search-on-arrow-key enabled, the visual errors happen when pressing up, and even on short lines.
I should point out that this happens on two different systems, both running Fedora 23.
This is a typical symptom of control characters in your prompt not being properly enclosed between \[ and \] (in PS1) or between 0x01 and 0x02 bytes (if emitted via PROMPT_COMMAND). Askubuntu and friends are full of this question, just one random example: http://askubuntu.com/questions/251154/long-lines-overlap-in-bash-ps1-customized-prompt, there's many more. It's quite unlikely to be a problem with konsole. (Just for the record, could you please try with a few other emulators, e.g. xterm and gnome-terminal, and share the result with us?)
Yes, you're right. It's a bash bug really, and that's a sufficient workaround.
It's not a bug in bash and not a workaround. It's documented in bash's manual that you have to use these characters.
It's surprising behaviour which (at least in my case) wastes a lot of time and could conceivably be solved at a higher level (even if what that means is Bash printing a warning about "PS1" not being the expected length, though IMO Bash should just deal with it). Does that not sound like a bug to you?
This is really not the right forum to discuss this. Bash/readline's documentation clearly says it needs to be done this way, so if it's a bug then it's a bug in your PS1 setup, not in bash. We might argue about bash lacking a cool feature that would make it more convenient for the users. The point is: - bash does not know which characters of the prompt are escape sequences, that is, will not advance the cursor when printed; - bash has no way to know what is actually printed on the screen and where the cursor is, and hence if/when the display falls apart. If you want to improve on this, it should be brought up (I guess it has been brought up many times) on bash's mailing lists (check its archives first). (I'm sorry but I'm off from this discussion here.)