05:08 <helmut> hi. thanks for foot. I'm having difficulties getting bold rendering working. setting bold-text-in-bright=palette-based improved things in vim, but printf '\e[1mbold\e[0mnormal\n' remains indistinguishable. I have a color scheme setting regular* and bright*. what should I be looking at?

05:14 <kode54> dnkl: disregard what I said, it was happening to chromium too

05:14 <kode54> I think Plasma 6.4.4 just busted

05:26 <helmut> hmm. bold-text-in-bright=yes used to (1.13) used to not render bold in vim, but now it does (halfway, recognizable, not great).

05:29 <dnkl> helmut: that option has never changed whether bold is used or not. Only if it _also_ is rendered brighter

05:31 <helmut> I suspect that my font does not have a bold variant

05:32 <helmut> xterm (where the visual difference is clearer) seems to paint each glyh twice with a 1px x offset to turn them "bold" (which you may call not great)

05:33 <dnkl> helmut: you can change how much brighter it gets. Or you could override font-bold to something of your own choice

05:34 <dnkl> https://codeberg.org/dnkl/foot/src/branch/master/doc/foot.ini.5.scd#L2034

05:35 <dnkl> and

05:35 <dnkl> https://codeberg.org/dnkl/foot/src/branch/master/doc/foot.ini.5.scd#L50

05:39 <dnkl> you can also look at "foot -d info" to see exactly which fonts it's loading

05:39 <helmut> I am not sure I how I never ran into that option. surprisingly foot tells me "error: foot: /home/helmut/.config/foot/foot.ini:28: [main].bold-text-in-bright-amount: 1.5: not a valid option: bold-text-in-bright-amount"

05:40 <dnkl> it's in the "tweak" section, not main

05:42 <helmut> sorry, for the pebcaks. I the doc's are right and clearly indicating that. and it just works.

05:43 <dnkl> no worries :)

05:47 <helmut> in any case, my foot.init seems to have reached bug-compatibility with xterm to a sensible extent and I can start learning all the new stuff that foot adds :)

05:48 <dnkl> heh, good to hear

05:48 <helmut> in day to day usage, the most annoying part still is containers lacking foot-terminfo

05:50 <dnkl> almost everything should be fine with the ncurses provided terminfo (i.e "foot", rather than "foot-extra"). I hear even Debian has a recent enough ncurses now a days...

05:50 <helmut> hmm. no. [main].bold-text-in-bright=yes made dimmed characters invisible. :-(

05:50 <helmut> dnkl: yeah, it's only pre-trixie where that is annoying

05:52 <dnkl> not sure how dimmed can end up invisible, but please file a bug report if you can reproduce it

05:54 <helmut> uhm. what looks dim on the screen (in xterm) is produced as "bold black" printf '\e[1m\e[30mdim\e[0mnormal\n'

05:55 <helmut> I'm not sure it is a bug or a feature

05:56 <helmut> and when foot increases the brightness of that black glyph, well then multiplying 0 doesn't get you anything different

05:57 <helmut> though irssi clearly expects that to display something

06:02 <dnkl> the result of "bold black" (assuming brightening is enabled) depends on both the color scheme in use, and by how much you brighten it, and the color schemes background color. So yes, there are many ways for that combination to end up unreadable, and applications should avoid it. Most modern applications don't use it

06:03 <dnkl> in foot's default color scheme it's perfectly readable,imho

06:06 <helmut> I cannot confirm on Debian trixie 1.21. I moved my foot.init out of the way and even after scaling up the font I cannot distinguish bold black from the background color

06:07 <dnkl> maybe you want bold-text-in-bright=palette-based instead of "yes"?

06:08 <helmut> with that setting, it becomes distinguishable, but then, I'm back to my original problem printf '\e[1mbold\e[0mnormal\n' becoming indistinguishable which was fixed by bold-text-in-bright=yes

06:09 <dnkl> the algorithm for brightening changed slightly in 1.22. perhaps that's why it's unreadable for you

06:10 <dnkl> (for "yes", not "palette-based")

06:12 <helmut> should bold white not map to bright0?

06:12 <helmut> err bright7

06:14 <dnkl> with palette-based, yes. As far as I can tell, it does, also in 1.21

06:14 <dnkl> and I've verified that "yes" is more readable in the latest release, compared to 1.21

06:16 <helmut> I anticipated foot getting better and hence deferred my foot tweaking until my trixie upgrade. %-)

06:17 <helmut> in any case, thanks a lot for having taken the time on end user support and for making wayland easier to adopt via foot.

06:19 <dnkl> you're welcome :)

06:19 <helmut> with bright7=ffffff and palette-based, I am quite sure that \e[1m is not displayed in white but some gray. if you consider that a possible bug, I can look into debugging and/or writing a bug report

06:19 <dnkl> 1m is not the same as regular7

06:20 <dnkl> 1m is "bold using the default foreground color"

06:20 <helmut> foreground=c0c0c0

06:21 <dnkl> with palette-based there's no corresponding bright color for the foreground color

06:21 <dnkl> which means the original color is used, unchanged

06:22 <helmut> that fully matches my observation

06:22 <dnkl> it's expected

06:22 <dnkl> by design

06:23 <dnkl> so yes, you'd have to go with "yes" instead, for that to work

06:24 <dnkl> but the correct answer is of course to not use application color themes that abuse bold. They should be using bright colors directly instead.

06:24 <helmut> not sure how to fix irssi

06:24 <dnkl> me neither, I'm afraid. don't use it

06:25 <dnkl> don't know how much freedom their color schemes have

06:25 <helmut> https://sources.debian.org/src/irssi/1.4.5-1/docs/formats.txt

06:26 <helmut> I found where %K (bold black aka dark gray) is being used in the default color scheme, but not where %K is implemented

06:31 <runxiyu_> Is it possible to let foot switch color themes via darkman?

06:33 <helmut> dnkl: is there some reference material I could include in an irssi bug asking for not using bold black?

06:34 <helmut> and is adding a bold foreground palette color an option?

06:34 <dnkl> runxiyu_: only if darkman has a custom "foot" backend. There's no generic Wayland protocol to signal theme changes, meaning foot has no way to receive theme change notifications. Except for its own built-in support: SIGUSR1 and SIGUSR2

06:35 <runxiyu_> alr, thx

06:35 <runxiyu_> i'll probably just use color-theme-toggle for now

06:36 <dnkl> helmut: don't really want to add that option, as the bold-is-bright thingy is now considered legacy by most terminal emulators, and are disabled by default in most of them

06:36 <dnkl> so, adding more options that encourage the bold abuse isn't something I consider a good idea

06:36 <helmut> sounds like I want an actual bold font

06:38 <dnkl> as for irssi - I would think that mentioning that bold-is-bright is off by default in most terminals is enough. I would consider it a bad idea to rely on a disabled feature in their default theme

06:40 <dnkl> and the fact that "bright black" (both via bold-is-bright and \e[90m) is unreadable, or at least have very low contrast, in many terminal color themes

06:41 <dnkl> if what they want is a "dimmed" white, why not use exactly that? i.e \e[2m (dim foreground), or \e[37;2m (dim white)

06:59 <runxiyu_> does foot emit osc 11?

07:00 <j`ey> yes

07:00 <dnkl> emit? it supports receiving it (and replies to the query variant)

07:00 <j`ey> I do a similar thing in my nvim config

07:01 <j`ey> and nvim by default uses OSC11 to check if bg should be dark

07:01 <j`ey> runxiyu_: https://github.com/neovim/neovim/blob/8d154e5927d728cc2ad74a0dec8b45fab1333f8c/runtime/lua/vim/_defaults.lua#L801

07:02 <runxiyu_> oh, hm

07:02 <runxiyu_> my nvim doesn't seem to behave this way :/

07:02 <runxiyu_> okay, --clean works

07:02 <runxiyu_> my bad

07:02 <runxiyu_> thanks! was just a config issue

07:40 <helmut> dnkl: thank you. I'll file an irssi report

07:53 <helmut> dnkl: regular0=333333 may be a sensible workaround for my use case though black no longer is black then

07:58 <helmut> dnkl: in the foot default configuration some form of bold-is-bright definitely is enabled. \e[1m is not just a bold font, but also brighter. (trixie 1.21) (and to me that's a feature, not a bug)

08:07 <helmut> once choosing a non-bitmap font, that dark gray stuff also works here. I didn't expect it to be font-dependent