dnkl changed the topic of #foot to: Foot - fast, lightweight and minimalistic Wayland terminal emulator || 1.13.1 || https://codeberg.org/dnkl/foot || channel logs: https://libera.irclog.whitequark.org/foot
ifreund_ is now known as ifreund
vyryls has quit [Quit: WeeChat 3.6]
ayushnix has quit [Ping timeout: 252 seconds]
Consolatis has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Consolatis has joined #foot
caveman has quit [Remote host closed the connection]
caveman has joined #foot
talismanick has quit [Ping timeout: 244 seconds]
jao has quit [Ping timeout: 264 seconds]
Ordoviz has joined #foot
caveman has quit [Remote host closed the connection]
baltazar has quit [Ping timeout: 252 seconds]
baltazar has joined #foot
vyryls has joined #foot
Ordoviz has quit [Ping timeout: 265 seconds]
Ordoviz has joined #foot
Biolunar has joined #foot
vyryls has quit [Quit: WeeChat 3.6]
Ordoviz has quit [Ping timeout: 252 seconds]
smudge-the-cat has joined #foot
smudge-the-cat has left #foot [#foot]
Ordoviz has joined #foot
talismanick has joined #foot
caveman has joined #foot
talismanick has quit [Ping timeout: 244 seconds]
jao has joined #foot
an3223_ has quit [Ping timeout: 258 seconds]
an3223_ has joined #foot
caveman has quit [Remote host closed the connection]
caveman has joined #foot
cabal704 has joined #foot
Ordoviz has quit [Ping timeout: 252 seconds]
cabal704 has quit [Ping timeout: 244 seconds]
cabal704 has joined #foot
ayushnix has joined #foot
ayushnix has joined #foot
ayushnix has quit [Changing host]
ayushnix has quit [Remote host closed the connection]
ayushnix has joined #foot
helmut has joined #foot
<helmut> hi. wow so many people. I expected you all to be on matrix or the like. anarcat sent me here. :)
<anarcat> maybe they *are* on matrix, no judgement ;)
<helmut> would someone like to support me in figuring out color configuration for foot? I happen to like the high contrast default of xterm and would like to replicate it on foot.
<helmut> foot 1.12.1-1 on debian, config https://paste.debian.net/1254563/ is my attempt
<helmut> err 1.13.1-1
<helmut> now when I use like ls, the blue used for directories is quite a bit darker on foot than xterm.
<helmut> in vim shell syntax highlighting, the red used for shArithmetic is red on xterm and hardly distinguishable from gray in foot
Ordoviz has joined #foot
ayushnix has quit [Remote host closed the connection]
ayushnix has joined #foot
<helmut> hypothesis 1: foot is ignoring my config. how would I debug that? hypothesis 2: I am configuring too little colors. how would I figure out what is missing? hypothesis 3: ???
<helmut> argument against hypothesis 1: the urgent bell works
<anarcat> screenshot? :)
<helmut> ugh. now I need to learn how to do screenshots on wayland %-)
<dutchie> running foot from a terminal will include useful information, such as whether it read your config file
<zdykstra1> grim + slurp
<dutchie> will output, that is
<helmut> dutchie: thank you. it tells me about my config file and the font being used and such. :) scratch hypothesis 1
Ordoviz has quit [Ping timeout: 244 seconds]
<helmut> thanks to zdykstra1, https://spock.subdivi.de/~helmut/foot/
<anarcat> uh! odd
Ordoviz has joined #foot
<helmut> I also happen to find the font hard to read, so recommendations on that side are welcome as well
<dnkl> helmut: for vim, try setting TERM=xterm-256color. They special case XTerm *a lot*
<dnkl> you should be able to use the same font as in XTerm
<dnkl> but might be named differently
<helmut> dnkl: I suppose you mean when using foot. I tried and was not able to observe a difference to leaving TERM at foot
<dnkl> if recommend just using echo or printf, with color escape sequences, to see whether the colors match
<anarcat> isn't there some ncurses color test?
* anarcat digs in his LWN article for the test thing
<dnkl> if they do, the issue is not with the colors themselves, but in how the applications have been configured
<anarcat> which is the "more thorough test run" in https://github.com/termstandard/colors
<dnkl> that won't show differences in the color theme configuration
<helmut> dnkl: you are right again. echo $LS_COLORS surprisingly is empty on foot
<dnkl> right, dircolors doesn't support TERM=foot out of the box
<dnkl> the latest release, or the next release, of dircolors will
<anarcat> dnkl: probably not, but it will show if there's correct truecolor support, just a sanity check
<anarcat> which some xterm, and definitely rxvt, fail at
<helmut> ok. that's awesome news! hypothesis 3 == applications behave differently on xterm vs foot <- the true one
<dnkl> anarcat: your script uses the wrong/invalid variant of the true color escapes where semicolons are used as sub parameter separator
<anarcat> dnkl: well it's not *my* script, it's the https://github.com/termstandard/colors thing :p
<dnkl> (granted, more terminals support that one, than the correct version)
ayushnix has quit [Remote host closed the connection]
zdykstra1 is now known as zdykstra
ayushnix has joined #foot
<dnkl> helmut: you might want to check out foot's wiki. it covers at least the dircolors issue
<anarcat> dnkl: what is the correct way of doing this?
<dnkl> but codeberg is down at the moment
<anarcat> oh wow, codeberg is down?!
<helmut> anarcat: remind me to post a followup comment on your blog. leaving it like that is unfair
<anarcat> helmut: please post a follow comment on my blog
<anarcat> or do you mean later :p
<helmut> hehe. well preferrably after I figured what vim does differently
<anarcat> heh
<dnkl> anarcat: ESC[ 38:2:⟨Color-Space-ID⟩:⟨r⟩:⟨g⟩:⟨b⟩
<dnkl> they're updating the site
<dnkl> helmut: I also have it on my to-do list to add (more) vim and emacs specifics to the wiki
cabal704 has quit [Quit: WeeChat 3.5]
<dnkl> neovim is usually better than vim att handling non -XTerm terminals
<dnkl> (in my limited experience)
<dnkl> one of the issues with vim it doesn't use 24-bit colors unless explicitly told to
<helmut> dnkl: if I do TERM=xterm-256color in both xterm and foot, vim looks the same (like my foot screenshot)
<helmut> dnkl: if I do TERM=xterm vim looks like my xterm screenshot and foot looks like my foot screenshot
<anarcat> if setting TERM=xterm-256color in xterm leads to wrong color in vim, you might have other problems than foot to solve :)
<helmut> so I guess that I'm actually using fallback colors (in xterm) that are used, because I'm not normally using the colorful xterm.
<helmut> and on foot (like xterm-256color), vim recognizes that all the colors are available and it uses them
<anarcat> dnkl: it looks like https://gitlab.gnome.org/GNOME/vte/-/blob/master/perf/img.sh does "the right thing" and (basically) allows you to pick separators
<dnkl> helmut: TERM=xterm will make vim use only 16 colors. TERM=xterm-256color (or TERM=foot) makes it use 256 colors
<helmut> dnkl: I think that's what I meant to say. so what I actually want here is change my vim color scheme to only use 16 colors :)
<anarcat> interesting that the script also just doesn't really work so well
<dnkl> that is, some colors defined by vim's color theme will get remapped to a "best fit"
<helmut> (rather than fall back to 16 colors)
<dnkl> helmut: i'd think setting TERM=xterm in foot would work then?
<dnkl> in any case, we don't provide any foot specific terminfos that only use 16 colors
<helmut> dnkl: I would expect as well. surprisingly, vim still uses more colors in that setting
<dnkl> helmut: how did you set TERM=xterm in foot? just so that we can rule out it being set incorrectly...
<helmut> dnkl: bash prompt $ TERM=xterm vim
<dnkl> alright, good. That looks right
<helmut> and no, I don't think foot should provide a 16 color terminfo. I should configure a color scheme rather than relying on the default
<dnkl> must be some 16-color themes available already, right?
<helmut> ok. so I actually messed up bold colors in my foot.ini https://paste.debian.net/1254563
<helmut> printf "\e[1;31mfoo\e[0m\n" # looks different in vim vs foot
<helmut> it looks slightly bolder (font weight) and very slightly lighter than non-bold (\e[0;31m) on foot. hardly distinguishable
ayushnix has joined #foot
ayushnix has quit [Changing host]
<dnkl> helmut: "bold colors"? There are no bold colors
<helmut> how do you call "\e[1m" vs "\e[0m"?
<dnkl> bold font. but color isn't different. by default at least
<helmut> I actally had that in my foot.ini, but it was commented out as it appeared not to work (due to vim using 256 colors and dircolors not working on foot)
<helmut> dnkl: thank you so much! I suppose all color mysteries are solved now
<dnkl> great :)
<dnkl> sorry for being somewhat brief. I've been on my phone up until now
<dnkl> anarcat: how did the script not work (assuming you referred to img.sh)? Tested it briefly and worked for me...
<anarcat> dnkl: in xterm, it just shows garbage
<dnkl> ah
<dnkl> the colon4-variant didn't work in xterm, but the other ones did, fo rme
<dnkl> which is interresting, because manually printing a "colon4" test-string works...
<dnkl> one issue with the script is that it emits color values that are out-of-bounds. I.e. lots of color values are outside 0-255. The result depends on whether the terminal truncates or saturates...
cabal704 has joined #foot
<baltazar> hello again! I have managed to narrow down the freezing issue I mentioned before. it seems to happen when there's terminal output and a title change in quick succession, but only if mouse.hide-when-typing=yes and the mouse is actually hidden
<baltazar> then, apparently foot waits for a frame done event
<dnkl> and this happens on sway master? Or with patches applied?
<baltazar> happens on sway master, sway with patches and even labwc master
<baltazar> I did not manage to reproduce it in tinywl though
<helmut> dnkl: I didn't perceive it as brief at all. I actually do like those pointers that make me look up the context and gain a deeper understanding than blindly copying stuff from irc. great experience
<dnkl> baltazar: is running 'while true; do echo -e "\e]0;$(cat /proc/uptime)\e\\ $(date)"; done' enough to reproduce?
<baltazar> no, because it unfreezes on any screen update, even updates from the same foot instance
<dnkl> I'm confused. You said it happens when there's terminal output. That implies screen update
<baltazar> ok, so if an update happens very close to a title change, then that screen update will fail to show (= "freeze"). however, if another screen update after this, that will unfreeze it
<baltazar> my current way to reproduce it is this: foot -c /dev/null -o mouse.hide-when-typing=yes sh -c 'let i=1; while read -s; do printf "$i\n\E]2;$i\a"; let i++; done'
<dnkl> ok, got it
<baltazar> then you have to keep pressing enter and watch carefully for a missed print. then if you try moving the mouse (without pressing enter!) you should see that it won't get "unhidden"
<baltazar> (of course, if blindly moving the mouse causes a screen update e.g. due to focusing a different window, that unfreezes it as well)
<dnkl> baltazar: hmm, counted up to 100 but didn't see any issues
<dnkl> latest sway+wlroots master
<baltazar> well, I get it in 20 on average...
<baltazar> is there anything besides foot on your screen? any screen update would immediately unfreeze it so you wouldn't notice anything
<dnkl> another foot instance, with zero output
<baltazar> hmm ok, in my main sway it seems harder to reproduce. the 20 average was in a nested sway
<dnkl> tested moving the foot test-window to a separate workspace
<dnkl> still nothing
<dnkl> I've been counting up to 100 many times now...
<baltazar> try in a nested sway with this config: https://termbin.com/lx670
<baltazar> also, make sure the mouse is hidden by foot, otherwise it won't happen
<dnkl> yeah, mouse is hidden, and hovering over the window I'm testing in
<dnkl> also tested a nested sway, still nothing
cabal704 has quit [Ping timeout: 244 seconds]
<baltazar> well, this seems highly timing sensitive. if I run it in my main sway, it seems that the screen update goes out before it freezes. this way there's no visual feedback that it's frozen, but if you try to move the mouse you can see that it remains hidden...
<Consolatis> failed to reproduce on labwc master on DRM as well. completely empty workspace (no panels or similar causing screen damage), got up to 100 and the cursor was hidden
<Consolatis> maybe its related to some adaptive sync setting or similar?
<dnkl> baltazar: can you still reproduce with foot's default config (+ hide-when-typing)?
cabal704 has joined #foot
<dnkl> (foot -c /dev/null -o mouse.hide-when-typing=yes ...)
<dnkl> oh sorry, you already had that...
<baltazar> hmm wait. I just tested in non-nested labwc and I can't reproduce it there
<dnkl> what I'm thinking is, if an update to *another* window unfreezes foot, then how can it be an issue in foot?
<dnkl> btw, did you solve your libwayland issue? (it logged an unrecognized request)
<baltazar> didn't do anything about that since
<dnkl> because if there are requests or events lost, then obviously anything could happen
<dnkl> tried that too, but still can't reproduce...
<baltazar> hmm
Ordoviz has quit [Ping timeout: 265 seconds]
jao has quit [Remote host closed the connection]
Nulo has quit [Read error: Connection reset by peer]
Nulo has joined #foot
jao has joined #foot
jao has quit [Remote host closed the connection]
jao has joined #foot
jao has quit [Remote host closed the connection]
Ordoviz has joined #foot
jao has joined #foot
midgard has quit [Ping timeout: 268 seconds]
midgard has joined #foot
baltazar has quit [Ping timeout: 264 seconds]
baltazaar has joined #foot
baltazaar is now known as baltazar
Ordoviz has quit [Quit: WeeChat 3.6]
leon-p has joined #foot
vyryls has joined #foot
cabal704 has quit [Quit: WeeChat 3.5]
Pound_Hash has joined #foot
Pound_Hash has quit [Quit: Pound_Hash]
Pound_Hash has joined #foot
cabal704 has joined #foot
Pound_Hash has quit [Remote host closed the connection]
cabal704 has quit [Quit: WeeChat 3.5]
cabal704 has joined #foot
cabal704 has quit [Client Quit]
rodrgz has joined #foot
rodrgz has quit [Quit: WeeChat 3.5]