docs: add truecolor info

[bashbunni]

Not sure if this should live in the README or in a dedicated docs section...
Will figure that out before merging. A review on the content itself would be
appreciated!

[bashbunni]

oh HA, I can add this back in. I thought I had accidentally added this

[bashbunni]

I don't even know if this sentence makes sense 😂 may need a lil tidy later

[caarlos0]

I think the chain of deps is more like wish -> lipgloss -> termenv

[bashbunni]

going to leave this part out for now given we're going to intro term changes soon which might include different default behaviour

[bashbunni]

Suggested change

	> Wish uses [termenv][termenv] under the hood, which will set truecolor for a few
	> Wish uses [termenv][termenv] under the hood, which will set `truecolor` for a few

[bashbunni]

Suggested change

	NO_COLOR vs CLICOLOR: if NO_COLOR is set or CLICOLOR=0 then the output should
	`NO_COLOR` vs `CLICOLOR`: if `NO_COLOR `is set or `CLICOLOR=0` then the output should

[tartavull]

I know this might not be the ideal place to ask, but I’m lost and desperate for a solution.

We have a Wish application that displays colors perfectly when run locally. Setting environment variables like NO_COLOR or CLICOLOR=0 correctly disables the colors as expected. However, when I deploy this Wish application to the server, it doesn’t display any colors.

I’ve tried the following steps without success:

1. Tested every available terminal.

2. Set SendEnv COLORTERM in the SSH configuration.
   Given this, and the wish app running locally seems like a strong indicator that the problem is the server and not the client.

3. Added bubbletea.MiddlewareWithColorProfile(teaHandler, termenv.TrueColor) to the application.

4. Set CLICOLOR=1, and making sure NO_COLOR is not set in the container.

Despite these efforts, the application still doesn’t display colors when run on a server. Any advice on what else I could try to resolve this issue would be greatly appreciated.

This description is more concise and clearly states the problem and the steps you’ve already taken to try to resolve it.

[caarlos0]

@tartavull I successfully made the bubbletea example (PS: need to serve it on 0.0.0.0 instead of localhost) work inside a container (with no colors, as you can see in the log), and clients got colors anyway:

The trick is to use a custom renderer for your lipgloss colors. By default, it'll use the one from the current environment, which in this case is the server, not the client.

So we need to make a new renderer using the client's info and use it instead. See

wish/examples/bubbletea/main.go

Line 81 in 43884f7

renderer := bubbletea.MakeRenderer(s)

Hope that helps.

We should probably document this, too.

All this should be improved in the v2 stack of everything.

[caarlos0]

fwiw @bashbunni I pushed some updates

I think we should probably merge this

[lictw]

@caarlos0 I read everything, tried to understand, but still couldn't..

If the colors are there when running locally, then why we can't do anything on a server/in a container so that they are there? Also locally, locally for the server, why is this not possible?

I have full featured application and I don't want rewrite full application and redefine all styles of external components (bubbles) with some custom renderer.. Besides deep-alpha v2, is there really no option at all?

[aymanbagabas]

fwiw, we maintain our own fork of gliderlabs/ssh and this library only provides abstractions on top of Golang's SSH implementation

Suggested change

	Wish uses [gliderlabs/ssh][gliderlabs/ssh] to implement its SSH server, and
	Wish uses [crypto/ssh](https://pkg.go.dev/golang.org/x/crypto/ssh) and [gliderlabs/ssh][gliderlabs/ssh] to implement its SSH server, and

[aymanbagabas]

If the colors are there when running locally, then why we can't do anything on a server/in a container so that they are there? Also locally, locally for the server, why is this not possible?

It's more complicated than how it seems. When you connect to an SSH server interactively, the SSH server daemon is responsible for opening a terminal, or a PTY, for the session to operate normally and run in a real terminal. During the connection initialization, and for security reasons, both the ssh binary (client), and the server only send/accept the $TERM environment variable (and other LC_* ones for localization).

For colors to work correctly, we need to send local terminal color environment variables such as $COLORTERM. This can be done using ssh -o SendEnv=COLORTERM option. Keep in mind that this might work with Wish because by default the Golang SSH server is permissive and accepts any environment variables sent from the client. This is not true with OpenSSH and sshd where you need to explicitly allow certain variables to be read from the client.

With the v2 stack, you can allocate real terminals and PTYs using the wish.NewServer(ssh.AllocatePty) option. This is useful beyond Bubble Tea when you want to use Wish for running a shell, for instance, or doing more complex SSH server tasks.

I have full featured application and I don't want rewrite full application and redefine all styles of external components (bubbles) with some custom renderer.. Besides deep-alpha v2, is there really no option at all?

You shouldn't rewrite and redefine styles and components. Bubble Tea and Lip Gloss v2 doesn't change much of the API and mainly focus on internal implementation. If you're using lipgloss.AdaptiveColor, you could use the new lipgloss/compat package to provide a compatibility layer for AdaptiveColor. Just keep in mind that this will only work locally against the terminal that runs the program (in this case, the server terminal running Wish).

This is because with AdaptiveColor, we need to know the terminal background color and capability before we run the program on the terminal. This wouldn't work with SSH server-client programs, since the server opens a new terminal for each connection, which means Bubble Tea has to query the new client terminal background color once it's created.

[lictw]

For colors to work correctly, we need to send local terminal color environment variables such as $COLORTERM. This can be done using ssh -o SendEnv=COLORTERM option.

But @tartavull said above, that there are no colors even with this variable sending.. Is this exactly enough for the v1 running on a server to show colors to the client?