Michael Enßlin added the comment:
Terry, i guess you are right; it is indeed not the job of python to know how
its terminal will print characters; there is a whole lot of issues to consider,
such as terminal unicode support, control characters, ansi escape sequences,
terminal-specific escape
Terry J. Reedy added the comment:
Please suggest the specific change in a specific place that you would like to
see. Message is ok, patch even better.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17337
Changes by Tshepang Lekhonkhobe tshep...@gmail.com:
--
nosy: +tshepang
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17337
___
___
Terry J. Reedy added the comment:
On Windows, both the command prompt interpreter and IDLE ignore special
meanings and print prompt as is. Line wrap to physical next line occurs at 80
chars and movable edge of window respectively.
Michael, in light of your last post, do you still believe a
New submission from mic_e:
With a prompt that uses ANSI color escape codes, python3 input() and python2
raw_input() behave incorrectly when it comes to the wrapping of the first line
- almost certainly due to the wrong string length calculation.
The line breaking occurs k characters early,
Ezio Melotti added the comment:
I can reproduce the issue, but only from the interactive interpreter while
using input() directly (Linux/py3).
I tried the following things:
$ ./python -c 'print(\x1b[31;1mthis is a bold red prompt \x1b[m, end=);
input()'
$ ./python -c 'input(\x1b[31;1mthis is
Michael Enßlin added the comment:
The issue might very well be strictly related to GNU readline.
I have both successfully reproduced it in a C program:
#include stdio.h
#include readline/readline.h
int main() {
readline(\x1b[31;1mthis is a bold red prompt\x1b[m );
}
gcc -lreadline
