incorrect encoding of prompt
urielz opened this issue · comments
Googler 3.3 is working for me on OS X Capitan except that the prompt is a bit messed up (see screenshot) Any tips on how to fix this? Thanks!
Your terminal emulator doesn't support reverse video (\e[7m). What terminal emulator is this?
I use iterm2 (https://www.iterm2.com/) but the OS X default terminal has the same issue..
That doesn't sound right at all. I'm an iTerm2 user on macOS. Please run
yes q | \googler hello >/tmp/googler.output
and upload /tmp/googler.output to gist.github.com. Make sure you don't lose any characters in the process (you can download the file yourself and compare the checksum to the original). I'll have a look.
Actually,
yes q | \googler hello | pbcopy
would be easier.
here's the output:
https://gist.github.com/urielz/566fd84ccdb105aa98639f4b82108b98
something that might help - If I pbpaste the output of yes q | \googler hello | pbcopy then the characters are encoded correctly...
Prints just fine here. iTerm2 3.1.20170919-nightly, macOS 10.12.6. TERM is xterm-256color. See screenshot below for Preferences->Profiles->Terminal->Terminal Emulation setting. I don't think it would be any different on El Cap; reverse video is extremely basic stuff.
You might want to check this on a clean VM if you can.
something that might help - If I pbpaste the output of yes q | \googler hello | pbcopy then the characters are encoded correctly...
Okay that's something. But this is not an "encoding" issue; it's not like \x1b is somehow wrongly "encoded", you're getting colors just fine.
UTF-8 xterm256 is my setup as well. I'll report back if I manage to fix it just in case someone else runs into this. Thanks for the help!
Another way to debug that I can think of is to use iTerm2's session logging. It logs every character printed to the terminal verbatim, so that's something to check. To enable, go to Profiles->Session->Miscellaneous->Automatically log session input to files in:.
Thanks. I will take a proper look when I find the time. For now I modified the line of code so it won't do reverse video. Feel free to close this, looks like it's an issue with my system anyway.
You don't need to modify the code. You can set the prompt to a host of color/styles other than reverse video. Read https://github.com/jarun/googler#colors.
Closing for now. Let us know if there's anything wrong with our code.
ok so this issue seems to be beyond reverse color. Using the --colors I can change all colors except for the prompt colors.
For example: googler --colors GKlgxa will give a prompt like this:
[30mgoogler (? for help)[0m
or googler t --colors GKlgxj
[91mgoogler (? for help)[0m
What happens if you set the prompt to normal?
googler t --colors GKlgxx?
And please try the -C option as well.
The only thing different about this prompt (from other colored stuff) is it's wrapped in an input call. So I would run the following simple script and see what happens
#!/usr/bin/env python3
input('\x1b[31mThis is a red prompt: \x1b[0m')OK. In order to narrow it down, what happens if you just run googler? Without any options. Same issue?
Also, do you use any alias to run googler? Run type googler to confirm.
In addition to my comment above, can you check if the following patch makes any difference?
diff --git a/googler b/googler
index a170c30..e6132d1 100755
--- a/googler
+++ b/googler
@@ -1620,11 +1620,13 @@ class Result(object):
fillwidth = columns - indent - 1
for line in textwrap.wrap(abstract.replace('\n', ''), width=fillwidth):
print('%s%s' % (' ' * indent, line))
- print('')
else:
- print('%s\n' % abstract.replace('\n', ' '))
+ print('%s' % abstract.replace('\n', ' '))
+
if colors:
- print(colors.reset, end='')
+ print(colors.reset, end='\n')
+ else:
+ print('')
def print(self):
"""Print the result entry."""
I can't think of any reason why it should yet, still...
yes I'm using an alias (alias news='googler -n 5 -N --url-handler reader').
But executing /usr/local/bin/googler gives the prompt:
7mgoogler (? for help)[0m
I tried the patch but still same result. Googler is working great for me except for this issue- which I can work around it by changing that line of code (to have no colors at all in the prompt). But I'm happy to keep on helping debug this is you think there's a problem with the code and you would like to pursue it...
What happens if you add the color codes manually to the message (instead of using the colors subsystem)? Does it show correctly?
I think the problem is input(). check this: https://bugs.python.org/issue17337
Unfortunately, I can't reproduce this myself to test anything. I'll have to bank on you and @zmwangx to figure out something.
In any case, this isn't critical so I'm fine even if we don't have a patch.
export DISABLE_PROMPT_COLOR=1
@jarun thank you! yes this works.
My pleasure!