Latest Betas cause 256 color graphic issues.
Thanks for filing an issue! Please answer the questions below so I can help you.
- iTerm2 version: 3.2.1 beta 2
- OS version: 10.14 Beta (18A377a)
- Attach ~/Library/Preferences/com.googlecode.iterm2.plist here (drag-drop from finder into this window)
- Attach a debug log, if possible. Instructions at https://iterm2.com/debuglog
- Are you reporting a performance issue or a hang? Please attach a sample. Instructions at https://gitlab.com/gnachman/iterm2/wikis/HowToSample
- Are you reporting a crash? Please attach the crash log. Instructions at https://gitlab.com/gnachman/iterm2/wikis/crash-logs
- Are you reporting excessive memory usage? Please attach a heap analysis: https://gitlab.com/gnachman/iterm2/wikis/heapshot
In the BETA (3.2 stable works fine), plugging in my macbook pro causes 256 color graphics to change, many blocks changing to black. Unplugging macbook returns them to normal. When unplugged, while resizing the iTerm2 window, graphics change to look fine again, once resizing is done, blocks turn black again. Again, this only occurs in the Beta, 3.2 stable and native terminal do not show this behavior.
Detailed steps to reproduce the problem:
- Unplug macbook pro
- Use ponysay (or similar) to produce a 245 color graphic (see screenshot 1) - the image looks fine
- Plug in macbook pro - now many of the image colors change to black (see screenshot 2)
- Unplug macbook pro - image returns to normal
What happened:
Plugging in the macbook pro causes 256 color graphics to change, many colors reverting to black.
What should have happened: Nothing.
Note: the following commands print out a 256 color output, but this does not show the behavior, it seems to be related to the specific graphic characters used in programs like ponysay.
~/Library/Preferences ❯❯❯ for i in {0..255} ; do
printf "\x1b[48;5;%sm%3d\e[0m " "i" "
i"
if (( i == 15 )) || (( i > 15 )) && (( (i-15) % 16 == 0 )); then
printf "\n";
fi
done