> Bash Version: 3.1
> Patch Level: 5
> Release Status: release
>
> Description:
> Hi,
>
> I have a nice color prompt:
> export PS1=$'\\[\017\E[10;0m\E[1;[EMAIL PROTECTED]:\\w\\$ \\[\E[0m\\]'
> and use UTF-8 locales everywhere.
>
> When the output of a command doesn't end with a newline, I could perfectly
> see it in bash 3.0 since the prompt was printed on its right:
>
> [EMAIL PROTECTED]:~$ echo -n foobar
> [EMAIL PROTECTED]:~$
>
> Is is also okay in bash 3.1 with 8-bit locales or with simple prompts.
> However, if both colors are used in the prompt, and an UTF-8 locale is in
> effect, the prompt overwrites the output:
>
> [EMAIL PROTECTED]:~$ echo -n foobar
> [EMAIL PROTECTED]:~$ ek:~$
> ^
> the cursor stands here
>
> (actually that leftover part of the prompt suggest that probably the prompt
> is printed twice, first at the right place (after foobar) and then at the
> end of the line).
If I'm reading this right, it's not a regression, per se. It's always
possible to fool the redisplay code by violating the assumptions it
starts with, e.g., that the cursor always begins at column 0.
One thing that bash-3.0 did, especially when using prompts with non-
printing characters in multibyte locales, was issue many more carriage
returns than necessary and display the prompt string multiple times,
throwing in some clear-to-eol terminal sequences. This resulted in
some redisplay errors.
Bash-3.1 redraws the prompt many fewer times (3.2 will be better still),
but redraws a prompt with invisible characters at least one extra time
in a multibyte locale, resulting in the behavior you see.
However, the real problem is that readline thinks the cursor is
somewhere other than it is, which causes errors in its screen position
calculations. Even if the prompt is redrawn only once, eventually it
will make a redisplay mistake.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live Strong.
Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
