bug-bash
[Top][All Lists]
Advanced

[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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]