<cbb>
what about with: foot --config=/dev/null tmux new-session htop
<cbb>
ericonr: hmm, actually never mind
<cbb>
I just noticed it's a side by side of outside and inside tmux
<cbb>
doesn't look like a contrast problem
<cbb>
ericonr: how many other terminals have you tried? just one?
<ericonr>
cbb: terminals -> like foot:
<ericonr>
?
<ericonr>
it used to look like normal on alacritty
<cbb>
ericonr: it'd be interesting to know if the same thing happens in any other terminals I mean
<cbb>
besides foot and alacritty
<cbb>
or besides foot even
<cbb>
I can't reproduce the problem.....otherwise I'd try a few myself
<cbb>
kitty and xfce-terminal would be good ones to try
<ericonr>
I have tilix as well, it werks
sosodank has joined #foot
<sosodank>
hey @dknl, i fixed up my ASU implementation, and [xray] suddenly got a lot chunkier on foot. looking into it
<sosodank>
hrmmm, maybe not, belay that feedback
<dnkl>
sosodank: I noticed yesterday, while running notcurses-info, that the ASUs where inverted in 9/10 times. I.e I got ESU before BSU. Could that be the reason?
<ericonr>
it loads the font twice, each time with different DPI
<ericonr>
so some entries are bigger and some smaller
<ericonr>
(seems deterministic which entry does what though)
sosodank has quit [Remote host closed the connection]
<dnkl>
ericonr: I agree it looks DPI related, but I think this is quite different. It's supposed to redraw *everything* on a DPI change
<dnkl>
are you seeing this on 1.6?
<dnkl>
ericonr: oooh, hold on... might be the new text run cache (text shaping) that's not being wiped
<ericonr>
dnkl: yes, 1.6.0
<ericonr>
can I help in testing that hypothesis?
<dnkl>
ericonr: absolute. give me a couple of minutes and I'll have a patch for you :)
<dnkl>
pretty sure this _is_ the cause
<dnkl>
there cached text run is never destroyed, except on exit
yyp has quit [Remote host closed the connection]
<ericonr>
ok, nice!
yyp has joined #foot
<ericonr>
a dpi-aware=no setting would still have hidden the bug, wouldn't it?
<dnkl>
ericonr: not necessarily. If we guess wrong monitor (that's whats happening here - we're guessing which monitor well appear on, and uses its DPI), then we would have gotten similar results if the scaling factor differed between the guessed and actual monitor
<dnkl>
cbb: it was perhaps sloppily expressed. we don't support e.g. RTL scripts, or anything that requires text shaping
<cbb>
ah, ok
<dnkl>
Unicode glyphs in general is no problem
<cbb>
yeah I thought that might be what you meant
<dnkl>
*codepoints
<cbb>
so that's just Hebrew and Arabic then
<cbb>
or are there others?
<dnkl>
cbb: those are the obvious ones. pretty sure there are more, that are either RTL, or requires text shaping. I know I've seen them, but they are less known
<dnkl>
of course, in theory, we now _do_ support LTR scripts with 3- or more column glyphs. But in reality, I think the only one that will actually work is emojis
<dnkl>
My point really, is that what we currently do, wcswidth(grapheme), is broken, and I'm pretty sure it's broken for any non-emoji LTR script as well. Hence #618 would be an improvement. But still far from correct
<cbb>
ah ok, much more nuanced than I thought
<cbb>
I thought you were just declaring all non-latin scripts aren't supported
<cbb>
lol
<cbb>
unsupported*
<dnkl>
cbb: I've updated the PR description. Hopefully it's a bit more clear now
* dnkl
is stressed out today
<cbb>
:) I'll try not to contribute to that
<dnkl>
cbb: no worries, you've only been helpful :)
<dnkl>
so far ;)
<cbb>
;)
<dnkl>
I'll be doing a 1.8.1 release _very_ soon. The fixes for the embarrasing URL key-binding bug, as well as the grapheme clustering issue needs to get out there. And your terminfo additions are _very_ welcome too
<cbb>
I wanted to make sure I understood the change, since I've been thinking about the problem of grapheme width from an app point of view too
<Arnavion>
Oh, I missed 1.8.0
<dnkl>
grapheme clustering issue not being #614, but the fact that we reset the grapheme clustering state after each codepoint
<dnkl>
Arnavion: if you want to, I can keep a (private) list of emails to send out release announcements in the future
<dnkl>
s/614/618
<Arnavion>
Should I PM you?
<dnkl>
Arnavion: sure, that, or email me. Mail is in the git log
<Arnavion>
Sent mail
<dnkl>
cbb: I think its better to do small incremental improvements to grapheme handling, rather trying to get everything correct from the get go. As I suspect that we'll never get to "get go" :)
<dnkl>
Arnavion: thanks, got it
<dnkl>
Arnavion: now I just have to remember to write that mail. Bash me with hammer if you don't get a 1.8.1 release mail (though exact release date is yet to be decided).
<dnkl>
:)
<ericonr>
dnkl: idk if that's the case for Arnavion, but you can send announcement email to all package maintainers via repology
<Arnavion>
Should I wait for 1.8.1 if the bugs you mentioned above are serious enough?
<dnkl>
ericonr: Arnavion: that would certainly be much easier. Repology doesn't automatically send emails to registered users?
<ericonr>
dnkl: I don't know if there's an automatic setup, but the advantage is you get a list of emails directly
<dnkl>
Arnavion: you might want to start looking at the packaging differences between 1.7 and 1.8 (especially wrt utf8proc). But yeah, I'm planning on a 1.8.1 release this week. Unless something comes up. So might as well wait
<ericonr>
still have to remember to send it ;)
<dnkl>
ericonr: sure. thanks, will look into it
<dnkl>
Arnavion: let me know if you are on the repology list for foot. I don't see you there yet. If not, I'll send emails to both repology and directly to you
cbb has quit [Quit: WeeChat 3.2]
<Arnavion>
So if I understand correctly, this website is supposed to automatically parse out the package owner from the distro's website, yes?
<Arnavion>
because I checked a bunch of packages for OpenSUSE and none of them have maintainers, so I assume they don't support getting that info out of build.opensuse.org
yyp has joined #foot
<dnkl>
Arnavion: certainly sounds like it. that's a bit surprising
<Arnavion>
It wouldn't help anyway, because it would get the wrong maintainer (it would get the OS repo's maintainer, not the devel package's maintainer)
<dnkl>
Arnavion: perhaps they know that, and ignore opensuse on purpose...
<Arnavion>
Yeah, it'd need a bit of spelunking
<Arnavion>
It doesn't help that the package name on build.opensuse.org and the package filename in the RPM repo isn't the same, because one b.o.o package is one RPM specfile, and one RPM specfile can generate arbitrarily many RPM repo packages
<Arnavion>
so I'm not sure they can even know what the b.o.o URL is without downloading the RPM and extracting the .spec
yyp has quit [Read error: Connection reset by peer]
yyp has joined #foot
yyp has quit [Remote host closed the connection]
yyp has joined #foot
yyp has quit [Read error: Connection reset by peer]
yyp has joined #foot
yyp has quit [Remote host closed the connection]
yyp has joined #foot
novakane has quit [Quit: WeeChat 3.2]
cbb has joined #foot
yyp has quit [Remote host closed the connection]
st3r4g has quit [Quit: おやすみ]
mvdan has joined #foot
testuser[m]1 has joined #foot
priner[m] has joined #foot
caughtquick[m] has joined #foot
mvdan has quit [Quit: node-irc says goodbye]
caughtquick[m] has quit [Quit: node-irc says goodbye]
priner[m] has quit [Quit: node-irc says goodbye]
testuser[m]1 has quit [Quit: node-irc says goodbye]