[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
From: |
Michaelll Lee |
Subject: |
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code |
Date: |
Tue, 22 Mar 2022 10:21:22 +0800 |
On Mar 21, 2022, 9:47 PM Chet Ramey <chet.ramey@case.edu> wrote:
> Unless told otherwise, it assumes that every character it outputs contributes
> to that physical cursor position.
Thank you Sir, for pointing out this clearly, and now I think my
previous thoughts would be my misunderstanding.
On Mon, Mar 21, 2022 at 9:47 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 3/21/22 5:00 AM, Michaelll Lee wrote:
>
> > While using non-printing characters without "\[...\]" proves to be fine in
> > versions prior to 5.x.x (e.g., many suggestions from some online forums
> > have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the
> > same configuration in 5.x.x is not as stable as the previous versions(i.e.,
> > "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the
> > unexpected behavior(STEP7) will happen).
>
> This has never been true.
>
> Readline's display relies on knowing the physical cursor position. Unless
> told otherwise, it assumes that every character it outputs contributes to
> that physical cursor position. Eventually, the incorrect value that results
> from non-printing characters will mess up redisplay.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code, L A Walsh, 2022/03/22