<bibek>
Hi, I see that repo features a bunch of themes. Are those there as a resources to be copied into the config, or is there a way to specify by name one of those themes in `foot.ini`??
armin has quit [Ping timeout: 252 seconds]
armin has joined #foot
<dnkl>
bibek: if you could the themes to your system, you can reference them by path in foot.ini, using the"include" directive
bibek has quit [Ping timeout: 265 seconds]
bibek has joined #foot
bibek has quit [Ping timeout: 260 seconds]
bibek has joined #foot
bibek has quit [Quit: WeeChat 3.3]
armin has quit [Ping timeout: 258 seconds]
armin has joined #foot
novakane has quit [*.net *.split]
Lord has quit [*.net *.split]
avane has quit [*.net *.split]
<rumpelsepp>
dnkl: That's a good point. These themes are not included in the AUR package.
novakane has joined #foot
Lord has joined #foot
avane has joined #foot
ollysmith_ has joined #foot
ollysmith has quit [*.net *.split]
<dnkl>
rumpelsepp: right, we're already packaging the example conf. Might as well include the theme files too
<sterni>
dnkl: I think foot should default to text representation since most stuff seems to expect that it is the default
<sterni>
dnkl: for example plain ↕ becomes an emoji in foot, causing a lot of stuff to get its width wrong because it is expected to be the single width text representation
<sterni>
you have to force text representation in foot currently by adding the text represenation selector (U+FE0E): ↕︎
<sterni>
I suppose we are going to see ☺ in text representation more often though as a drawback
<sterni>
☺︎ is cute too :)
<dnkl>
sterni: single-codepoints don't go through any shaping at all at the moment. Not sure what the impact of doing that would be...
<sterni>
dnkl: so this is caused by plain font fallback?
<sterni>
i. e. is the emoji font preferred for all codepoints?
<dnkl>
Foot doesn't prefer anything. It depends on how you've configured fontconfig. And of course the fallback list in foot
<dnkl>
To be able to handle default representations, fcft would need to build a table from the Unicode-data, and do a lookup every time a (new) codepoint is rasterized.
<dnkl>
Patches welcome ;)
<dnkl>
sterni: there's lots of room for improvement... fcft_grapheme_rasterize() does look at the representation byte. That's why it works in foot. But fcft_text_run_rasterize() does not...
bisco_ is now known as birger_
<dnkl>
sterni: do you remember where the default representation is documented? It would be nice if fcft could get better at this...
birger_ is now known as birger
<dnkl>
rumpelsepp: updated meson.build to install themes to $datadir/foot/themes. Installing/updating foot-git should be enough to get them
birger has quit [Changing host]
birger has joined #foot
<sterni>
dnkl: ah yeah I think the problem is then that the fontconfig emoji thing is quite aggressive because it wants to avoid the accidental use of the text emojis in fonts maybe?
<dnkl>
sterni: not sure fontconfig bothers with representation at all, actually. But yes, it's usually pretty aggressive about preferring color emoji fonts
<sterni>
so it seems like you should always respect the presentation selector
<sterni>
and then if you have a strong preference just stick to that if neither is given
<sterni>
otherwise respect the Emoji_presentation boolean from the data files
diniwed has joined #foot
<sterni>
so I suppose the fcft needs to record the Emoji_presentation value as well now
novakane has quit [Quit: WeeChat 3.3]
novakane has joined #foot
diniwed has quit [Ping timeout: 260 seconds]
diniwed has joined #foot
feinedsquirrel has joined #foot
feinedsquirrel has quit [Ping timeout: 260 seconds]
feinedsquirrel has joined #foot
<feinedsquirrel>
what is the difference between foot and foot-direct terminfo files?
<dnkl>
feinedsquirrel: foot-direct a truecolor version, while 'foot' is 256-color only. But, note that the terminal itself is always capable of truecolor. Furthermore, most applications look at the environment variable COLORTERM to determine truecolor support
<dnkl>
truth is, the only application I'm aware of that requires a *-direct terminfo for 24-bit colors is emacs
<dnkl>
and that will change with the upcoming emacs-28, where they too have support for the COLORTERM env variable
<dnkl>
in 99% of the use cases, 'foot' is the one you want
<feinedsquirrel>
Oh, cool, thanks for the quick reply. Just to make sure I understand, most applications respect COLORTERM, and so likely will still show truecolor (provided COLORTERM is defined) even though I'm using the 256-color "foot" terminfo?
<feinedsquirrel>
If I'm understanding what truecolor means. If I'm off, I can look that up
<dnkl>
feinedsquirrel: that's correct. And foot always sets COLORTERM, so it's nothing you need to do manually
<sterni>
feinedsquirrel: truecolor is 24bit (rgb) color
<dnkl>
yes
<feinedsquirrel>
awesome. Thanks! One other question, on Arch, do I copy /usr/share/foot/foot.ini into .config/foot/foot.ini? I apparently don't have XDG_CONFIG_HOME defined. I could define it, but wondering if it should still work
<dnkl>
feinedsquirrel: copying it to ~/.config/foot/foot.ini is what you want
<sterni>
yes $HOME/.config is the specified default value of XDG_CONFIG_HOME
<dnkl>
most systems don't set XDG_CONFIG_HOME, but rely on its default value ($HOME/.config)
<dnkl>
sterni: I wrote a script that parses the emoji data you linked, pulling out all "Emoji" codepoints, with a their default representation being "text"
<dnkl>
got 219 codepoints
<feinedsquirrel>
cool, thanks a bunch! Looking forward to using this more, as I slowly switch everything from X to wayland.
<sterni>
dnkl: that's not that few actually
<dnkl>
that's easy to put into a sorted table, and should be quick to b-search through
<dnkl>
sterni: yeah, I thought it'd be fewer
<dnkl>
but still, not that many
<sterni>
yeah should be fine
<dnkl>
max 8 b-search iterations per lookup
<sterni>
actually the count kind of checks out considering the amount of historical cruft they accumulated into emoji
<dnkl>
and that's just the first time a codepoint is rasterized
<dnkl>
then everything is cached
<dnkl>
I can probably fix fct_glyph_rasterize(), and fcft_grapheme_rasterize(). Those are the ones foot uses
<dnkl>
fcft_text_run_rasterize() will be more difficult, but not impossible, obviously
<dnkl>
sterni: yeah, I noticed '#', '*' and '0
<dnkl>
' - '9' being in that list
feinedsquirrel has quit []
<sterni>
dnkl: interesting, I suppose you usually input them with the selector
<dnkl>
To get them as emojis, yeah, I guess. They typically work as expected since most fonts have them. I.e we never accidentally render them as emojis, because we never have to use a fallback font
<dnkl>
"never" meaning "almost never" 🙂
feinedsquirrel has joined #foot
<feinedsquirrel>
dnkl: some other questions, in the Arch Linux section of the install.md page, it says the bundled pkgbuild (I read this as the one in the repo as opposed to the one in the AUR) requires fcft and tllist, and then in the next paragraph says "note that it will do a [pgo] build..." Does that mean the AUR pkgbuild does not do PGO by default, only the bundled one does? (I guess my question is, which...
<feinedsquirrel>
... version of PKGBUILD does the word "it" refer to?) From reading the PKGBUILD themselves, and comments on the aur page, it seems the AUR version does use PGO
<dnkl>
feinedsquirrel: both do PGO
<dnkl>
In fact, the docs are wrong; the AUR package also depends on tllist and fcft being installed
<dnkl>
(it used to build them as sub-projects)
<dnkl>
FWIW, I've been meaning to remove the bundled PKGBUILD, just never gotten around to it... 😅
brocellous has joined #foot
<sterni>
dnkl: yeah nixos' fontconfig thing is a bit aggressive in that regard, but fair enough, I think you want to prevent the case where ☺️ comes from DejaVu Sans
<feinedsquirrel>
dnkl: I wondered if the docs were a bit old, no worries! Thanks for responding.
<dnkl>
sterni: a question; if we're shaping am emoji without a variation selector, should we fail, or fall over to an emoji font (if the default presentation is text)?
<dnkl>
feinedsquirrel: I'll try to update them soon :)
<feinedsquirrel>
No worries, documentation is often a project in and of itself! :)
<feinedsquirrel>
thanks again!
<sterni>
dnkl: I think text then
<sterni>
but it could be overrideable by some sort of global configuration
<sterni>
so that application could specify that they prefer text or emoji presentation regardless of the default if no selector is specified
<dnkl>
sterni: let me rephrase the question; regardless of which presentation type we're looking for - if we can't find a font, should we retry all fonts again, but this time not forcing a presentation?
<sterni>
having the wrong presentation than having none is probably better?
<sterni>
could lead to confusing behavior, though
<brocellous>
How would you place an xdg activation token into the foot client protocol?
<brocellous>
Currently footclient dodges the naive pid-to-workspace matching in sway
<brocellous>
Basically the idea is to read XDG_ACTIVATION_TOKEN from the env, send it to the server, and have the server use it to activate its surface before map.
<dnkl>
brocellous: hmm, without thinking too much... I'd add a flag in the protocol struct, and then send the actual value after the struct, just like option overrides are handled