-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
colors working incorrectly on tf #116
Comments
We got more than one tf5 user with the same symptom, in the same running instance, where a telnet user sees no problem, so... maybe this is something reproducible with the use of tf5. Also, "after doing an .who everything is green, so it is as if the color reset command never came in." |
|
This seems like a tf5 bug. Here's a command repro'ing it:
This works well on several clients but not on tf5: While what is sent to the user is:
tf seems to completely ignore the "grey" command, and shows it all as blue. |
tf indeed does not support 39m:
|
According to the ANSI standard, 39 is "Default foreground color". While it is tf's fault that this isn't supported we should probably figure out a way to acomodate this (other than "disable colors"). Sending resets more often (eg,, after the output of each command) might be an interesting precaution, and mitigate (even if not totally fix) this issue. I need more time to think, but... I might want to do two things here:
|
Issue opened in tf5: |
An after command reset will cause some problems, and would not fix all the potentially affected people (since we would only be able to send the We could - temporarily - hack all the writes and replace 39's by 0's (fg defaults with resets), but that would need to be fixed as soon as we tried to use background colors. |
Well... better yet, we can replace 39's by a default color (eg. white), that can actually be configurable in the talker. That would actually turn a "clients limitation" into a feature. Also, we should also deal with 49's (Default background color), which suffer from exactly the same problem. |
Unlike with the foreground color, there is a big difference between painting with a (talker defined) foreground color (instead of using the client-defined), and painting with a talker defined background color instead of using the clients: the background color might only affect the areas where text exists, and if you have a client with transparencies and so on, there's a big difference between having a defined background color and having none. ie, we should probably find a way to "partially reset" colors... If we get a 39 (default foreground color), se can instead send a reset (0) + the previously defined background color (which we would need to know). And vice-versa. Doing this is a PITA unless it is done by chalk itself. Chalk has no way to do that now, and isn't properly "extensible" in order to do that. It might be feasible to alter chalk in order to support a "partial ANSI" mode that does not know 39 and 49 and deals with 0's instead... to investigate. |
Now that #87 is done, not only we have a reset in place, but it might even be triggering on the right places already. |
While using the Talker with tf5 within tmux the colors changes for unknown reason.
Its lines over lines in for example green, than it changes to blue for a lot of lines than blue.
I could not see any trigger to that.
The text was updated successfully, but these errors were encountered: