Summary: | readline's history search on up/down arrow keys visually messes up the edit line | ||
---|---|---|---|
Product: | [Applications] konsole | Reporter: | Diggory Hardy <kde2> |
Component: | history | Assignee: | Konsole Developer <konsole-devel> |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | CC: | egmont |
Priority: | NOR | ||
Version: | 16.08.1 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Diggory Hardy
2016-11-09 10:10:41 UTC
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.) |