04:27 <feinedsquirrel> just found that $COLORTERM is not set over ssh. Not sure if this is a product of my config, using foot-extra, or something else. I've got two machines using identical configs, locally at each one $COLORTERM echos "truecolor", but when I ssh into one from the other, it echos a blank line

04:32 <feinedsquirrel> putting off for now a whole slew of issues that I've just potentially found, if I ssh into one box from the other, then run "$ tmux" on the remote, $COLORTERM echos "truecolor", and e.g. "$ ls" prints with color.

04:33 <feinedsquirrel> so I guess my question is, is it expected that I need to set COLORTERM manually when I ssh into a remote box? (and if I don't want to start tmux)

07:42 <cbb> feinedsquirrel: try adding `SendEnv COLORTERM` to your ~/.ssh/config

07:44 <eckshton> anybody know how to get foot to cleanly draw to edges of screen like alacritty?

07:46 <cbb> eckshton: you're going to have to be more specific than that

07:47 <eckshton> foot leaves a couple pixel gap between the last character and the width of the window. i've disabled padding, but i still see this. alacritty, with the same font size, won't have this gap.

07:51 <dnkl> eckshton: I don't see a gap. Please provide a one-line reproducer, along the lines "foot -c /dev/null -f <font> -o pad=0x0 --window-size-chars=NxM ..."

07:51 <dnkl> and preferabĺy, a link to a picture showing the issue (when launched using the same one-line reprocuder)

07:56 <cbb> maybe it's a maximized window and foot/alacritty don't have the same cell size at the same font size?

07:56 <cbb> i.e. just pure luck

07:56 <eckshton> no, i just figured it out. alacritty was apparently adding a 1 pt padding between characters

07:57 <eckshton> just added the same to foot, it's good now

07:58 <eckshton> didn't notice till i took pics and flipped between them

08:02 <feinedsquirrel> I just added "SendEnv COLORTERM" to my ssh client config, and "AcceptEnv COLORTERM" to my ssh host sshd_config. $COLORTERM does echo "truecolor" now, and "ls" does print with colors. So is this just a limitation of what ssh allows, or is there a different way that foot can declare colorterm? I've only dove into LS_COLORS a tiny bit, would that be another way to solve it? I'd rather not have to

08:02 <feinedsquirrel> "AcceptEnv" in the root sshd_config for each server I connect to.

08:03 <dnkl> foot can't do anything else here

08:04 <feinedsquirrel> got it, thanks for verifying!

08:04 <dnkl> you could manually export COLORTERM in your shell RC scripts on the remote

08:05 <dnkl> perhaps behind a "if TERM == " guard

08:06 <dnkl> ideally (from our perspective), ssh should send COLORTERM automatically, just like it does with TERM

08:06 <dnkl> but they probably don't deem it (the variable) enough standardized

08:07 <dnkl> and given how many different env variables (some) terminal emulators set, they may be right in being conservative

08:12 <cbb> feinedsquirrel: dnkl: personally, I work around that kind of issue by setting LS_COLORS directly in my shell config

08:12 <dnkl> for LS_COLORS, I agree

08:12 <cbb> with some custom detection for color support

08:13 <cbb> (which includes checking if $TERM is foot)

08:14 <cbb> ...or more specifically: case "$TERM" in *-color*|*-16color*|*-256color*|*-direct|linux|foot)

08:15 <feinedsquirrel> yeah, that all makes sense. exporting it in a shell rc script on the remote seems easier, I was considering just exporting it manually after login at the beginning of longer sessions.

08:16 <feinedsquirrel> Or I'll dive into LS_COLORS. Problem is I'm going to want to customize some of them :) Thanks for that guard, cbb:

08:17 <feinedsquirrel> cbb: can you verify if setting LS_COLORS in /etc/environment still gets used when ssh-ing into a remote? Reason I ask is because I thought since foot is installed on the remote, and sets COLOR_TERM, it should be available, but I was mistaken that foot will only set COLORTERM upon starting the window, and ssh doesn't use the remote's "foot" to start the window.

08:19 <cbb> feinedsquirrel: the shell is running remotely, but foot is always running locally

08:19 <cbb> that's the whole point of a terminal

08:20 <feinedsquirrel> yeah, that's what I came to after thinking about it a bit longer. :)

08:20 <cbb> I'm not sure about /etc/environement, but the remote shell will load the remote shell config

08:22 <cbb> if you have other things that rely on COLORTERM, perhaps dnkl's suggestion would be better than mine

08:22 <cbb> i.e. setting COLORTERM from your shell config, depending on the value of "$TERM"

08:24 <feinedsquirrel> :thumbsup: I'll give it a try once I get the rest set up. From reading the wiki home page, it seems all of this came about because dircolors? I don't believe I have other things that depend on COLORTERM, but, I'm not a pro at this stuff, as you've probably deduced. :) Might end up defining both to cover all bases.

08:25 <dnkl> typical example would be editors, like vim or emacs

08:25 <cbb> dircolors is usually what sets LS_COLORS

08:25 <cbb> it's just a very over-engineered way of setting a single env var

08:27 <cbb> with it's own config etc.

08:27 <cbb> but you can literally replace the whole thing with something like that guard I mentioned above and then manually setting the variable

08:28 <feinedsquirrel> vim has the same syntax coloring on remote as local, without sending COLORTERM. So, I think that indicates it is relying on remote's LS_COLORS, and not COLORTERM?

08:30 <feinedsquirrel> yeah, I've tinkered with generating an LS_COLORS using dircolors in the past, then manually setting LS_COLORS, I just never got to the point where I understood it enough to feel comfortable leaving it uncommented in my shell config. It is still in there, commented out. I think it was because a small manual tweak was not generating the output I expected/wanted, so I placed it on the backburner.

08:30 <cbb> LS_COLORS is used by ls and maybe a few other things... I don't think it has anything to do with vim

08:31 <cbb> I could be wrong though, I'm not a vim user

08:34 <feinedsquirrel> makes sense. I'm looking through my vimrc, but I got a bunch of it from a friend who is much more a vim power-user than I am. Could be something in there. :shrug: Meanwhile, I've pasted your guard into my config next to my commented-out LS_COLORS definition. Hopefully I get around to testing and finishing that up this week. I've got about 4 other things I'm trying to solve in my free time right now.

08:35 <feinedsquirrel> :)

08:43 <feinedsquirrel> cbb: Oh, one other thing, I assume it is safe to add "foot-extra" to your guard?

08:43 <dnkl> not all vim themes are/require truecolor, afaik. Some (probably the default one too) use the base 16 colors

08:43 <dnkl> fein

08:43 <dnkl> feinedsquirrel: just use "foot*"

08:44 <feinedsquirrel> wondered that! :) awesome, thanks

08:51 <cbb> feinedsquirrel: https://pastebin.com/Xd7CUaCe

08:51 <cbb> that's the full snippet

08:52 <cbb> you can use foot* or add any other $TERM that supports colors

08:53 <cbb> the `tput` fallback should cover almost everything... the `case` part is just to avoid sub-processes for the common case

08:58 <feinedsquirrel> That is awesome, thank you for sending the whole thing! And thanks for the explanation that `case` avoids sub-processes. I didn't know that before. Is that just for speed? Might be able to alter a couple lines in my own shell scripts (all 4 of the primitive ones that I've written :D ).

09:02 <cbb> no worries

09:03 <cbb> it's partly for "speed" and partly just in case `tput` isn't available for any reason

09:05 <cbb> although that's not too likely and not having colors isn't the end of the world haha

23:29 <ljackson330> hey. trying to set the colour of the text in the csd window bar/title but am having some issues. poked around the manpages and have spent some time googling but have not been able to figure it out. i tried just adding font=cantarell:color=FFFFFFFF under [csd] (as well as the regular six-digit hex code) and that doesn't seem to work. is it perhaps

23:29 <ljackson330> just pulling from one of the system default colours?

23:31 <ljackson330> i guess since the bar colour defaults to the foreground, the text colour probably defaults to the background? but i don't see any way to edit that

23:37 <ljackson330> lol, yeah - it does. but that doesn't really work as a solution for me... want to keep the background and just edit the window bar text colour on its own

23:37 <ljackson330> any help much appreciated :)