commit 0fb7dd674c9969d55c21fca9040f7f7bcfd09950 Author: Damian Johnson atagar@torproject.org Date: Tue Sep 13 08:58:29 2011 -0700
Adding back the color prompt, with padded prompt
This is a hack to maintain a color prompt while sidestepping the 'http://bugs.python.org/issue12972' bug in *most* use cases. This pads the prompt so the original issue doesn't manifest unless the user's input exceeds around sixty characters or so. However, it introduces a new bug where tiny terminals (smaller than the padded width) get screwed up.
This obviously isn't a great situation and it could be argued that a colored prompt isn't worth these issues. However, the problem use cases strike me as being fairly rare (and I much prefer the green and bolded '>>>') so going with this for now. Patches welcome if someone has a better solution. --- src/util/torInterpretor.py | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/util/torInterpretor.py b/src/util/torInterpretor.py index fc217f3..2c4e7fa 100644 --- a/src/util/torInterpretor.py +++ b/src/util/torInterpretor.py @@ -495,9 +495,18 @@ def prompt(): # Cycling history via the readline module with up/down is buggy with a color # prompt. For more information see: # http://bugs.python.org/issue12972 - #prompt = format(">>> ", Color.GREEN, Attr.BOLD) + # + # To work around this while keeping a color prompt I'm padding the prompt + # with extra reset encodings so its length is non-rendered higher (around + # sixty characters). There's two ways that this can go wrong... + # - if the user uses up/down to display input longer than this non-rendered + # length then the original bug will manifest (screwed up prompt) + # - if the terminal's width is smaller than the non-rendered prompt length + # then the cursor and some movement will be displaced + + prompt = format(">>> ", Color.GREEN, Attr.BOLD) + prompt += "\x1b[0m" * 10
- prompt = ">>> " input = ""
# sets up tab autocompetion