Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

urxvt term colors issue #21

Closed
nkoturovic opened this issue Feb 25, 2019 · 4 comments
Closed

urxvt term colors issue #21

nkoturovic opened this issue Feb 25, 2019 · 4 comments

Comments

@nkoturovic
Copy link
Contributor

nkoturovic commented Feb 25, 2019

Description

After executing any cppurses tui program in some terminal emulators (tested with multiple versions of urxvt, and st(simple terminal)) some of the terminal colors get modified.
Colors: 239-254 after end of program execution (with or without interrupt) look different.
Screenshot: terminal color test
I'm using Arch Linux
Tried with following packages:

URXVT

  1. community/rxvt-unicode (9.22-7)
  2. aur/rxvt-unicode-intensityfix (9.22-12)

st - Simple Terminal

  1. aur/st (0.8.1-1)

Additional info

st (Simple terminal) logs to stderr:

# at cppurses program execution start
erresc: unknown csi ESC[22;0;0t
# at cppurses program end
erresc: invalid color (null)
erresc: unknown csi ESC[23;0;0t
  • On the other hand, using some other terminal emulators: lxterminal or xterm issue described above does not occur.
@a-n-t-h-o-n-y
Copy link
Owner

The latest commits in the develop branch should patch up the color differences for normal exit and on SIGINT
fa13145

I can't get the stderr to reproduce on st, I did remove an environment variable that was being set by the library to force ncurses to use xterm-256color control sequences, that might have had something to do with it. Removing this seems to not allow ncurses to change color definitions on st, so you'd have to set the TERM variable yourself before running the program if this occurs. TERM="xterm-256color"

@nkoturovic
Copy link
Contributor Author

nkoturovic commented Feb 27, 2019

I think that the assumption you've made is right (about st, but it reflects on other terminals as well).

According to this: for example urxvt and xterm control sequences differ. If I'm correct, these inconsistencies between terminal emulator's different esc codes should be resolved by Terminfo library/database which is used by emulator (by setting $TERM) and usually comes with ncurses.

After your patch, I've tested demos from devel branch, and now everything seems to work just fine with URxvt (color differences on normal exit/SIGINT).

However st behaves as you've described (in terms of displaying colors), but installing the newer version of st from AUR. (aur/st-git 1:0.7.9.g8c99915-1)
Additional terminfo files got generated by package: located in /home/$USER/.terminfo/s/ besides the usual ones which were located at (/usr/share/terminfo/s/) -> provided by ncurses::terminfo.. With this new terminfo, coloring problems disappeared. Removing new (package generated) st terminfo files, the home directory ones, it switches to using old (/usr/share) ones and the color problem appears again (I assume that badly written terminfo file declare that color changes are not supported by st).

st logs messages about codes ESC[22;0;0t and ESC[23;0;0t to stderr only if is not using appropriate terminfo file associated with the terminal emulator.
For example if $TERM set to xterm-256color then it will use terminfo for xterm and therefore ESC codes are not compatible with st so it will log those messages.

@nkoturovic
Copy link
Contributor Author

nkoturovic commented Feb 28, 2019

Accidentally closed issue, sorry for that.

After fix: fa13145
I have noticed probably unwanted behavior (because of relying on initscr() which relays on $TERM properly set). Next example results in error and program termination:

TERM="foo"  # Change $TERM to foo
./demo # executing cppurses demo
# Instead of executing (error prints -> from ncurses::initscr())
Error opening terminal: foo.   # With exit code (1)

Pointing that there is maybe a problem, it might be solved some other (better) way.
Tried to fix it with this patch: #22

1) If could initialize with `$TERM`  -> okay
2) if not then -> Try to initialize with xterm-256color
3) if both failed then -> Handle error (TODO)

This solution prevents potentially undesired exit(), but on the other hand hint that there is a problem with $TERM (shown at exit) might be useful for the end user to know.

INFO: Unfortunately some terminfo files are not written correctly, and that may cause coloring problems as one occurred with st after your patch. Not sure if there is a better solution than relying on terminfo files, it might be possible to avoid potential ''Coloring'' issues. And I agree that expecting xterm esc codes compatibility from random terminal emulator might not be the best solution, but it actually looks like it is more likely to work that way (in various terminal emulators) .. Previously archived with:

 setenv("TERM", "xterm-256color", 1);
// or manually setting TERM variable in shell

But as we already discussed, this sometimes causes those esc code errors like in st.

Note: In ubuntu, ncurses-dev package does not provide terminfo files, but there is package: ncurses-term to get them.

Also I run on some color issues using Konsole (on KDE-Neon), both before and after fa13145 (similar to st colors issue).. With $TERM set to xterm-256color (which is default) and with ncurses-term provided konsole-256color terminfo.

Unrelated

  • A colleague of mine and I have had used (and misused with hacks probably :D ) this library for the school project last year, and we found it very cool and enjoyable. Pluton

@a-n-t-h-o-n-y
Copy link
Owner

Thanks for the patch to handle screen initialization gracefully. It seems like this is a good solution for now, fixing all of the color issues on all terminals is a larger issue than this project tries to solve.

Looks like konsole does not implement changing color definitions seen here.

Though it does appear that things like htop and vim display colors correctly in konsole and st, htop uses ncurses and vim does not(as far as I know), so there must be a solution out there.

Also, thank you for the link to your project! It's exciting seeing this library being used outside of my own projects :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants