Bug 372250 - readline's history search on up/down arrow keys visually messes up the edit line
Summary: readline's history search on up/down arrow keys visually messes up the edit line
Status: RESOLVED NOT A BUG
Alias: None
Product: konsole
Classification: Applications
Component: history (show other bugs)
Version: 16.08.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-09 10:10 UTC by Diggory Hardy
Modified: 2016-11-11 08:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diggory Hardy 2016-11-09 10:10:41 UTC
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.
Comment 1 Diggory Hardy 2016-11-09 10:13:46 UTC
Correction: even without history-search-on-arrow-key enabled, the visual errors happen when pressing up, and even on short lines.
Comment 2 Diggory Hardy 2016-11-09 10:19:26 UTC
I should point out that this happens on two different systems, both running Fedora 23.
Comment 3 Egmont Koblinger 2016-11-10 20:28:25 UTC
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?)
Comment 4 Diggory Hardy 2016-11-10 22:17:02 UTC
Yes, you're right. It's a bash bug really, and that's a sufficient workaround.
Comment 5 Egmont Koblinger 2016-11-10 22:18:13 UTC
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.
Comment 6 Diggory Hardy 2016-11-11 08:22:01 UTC
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?
Comment 7 Egmont Koblinger 2016-11-11 08:36:11 UTC
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.)