01:54 <dnkl> rockorager: I haven't measured. I suspect explicit width to be more expensive though.

01:54 <dnkl> without it (i.e. with 2027), foot has to do grapheme clustering (and thus backwards lookup in the grid), which _is_ slow. But OSC-66 means processing an large escape sequence in the VT state machine, converting strings to numbers etc. I suspect that has a higher cost

02:15 <rockorager> hmm ok. I think I’ll switch the precedence then

02:16 <rockorager> I am blindly using it for any grapheme that is > 1 wide

02:16 <rockorager> “blindly” meaning blind to if I need to be explicit or not…not blind to support

16:19 <ovf> interesting, so continuing with the flag theme, foot's behaviour seems to be the opposite of firefox address bar (the only other gui program i've got to hand). my methodology: having put foot in raw mode, for every utf8 codepoint i read, i print it and then send a dsr request to get current cursor position. i then record both the codepoints and the positions -- that's my mapping.

16:21 <ovf> 🇬🇧: ((0xf09f87ac;0xf09f87a7);2 3) -- i.e. two codepoints, each advances the cursor one cell. firefox deletes wholesale

16:22 <ovf> 🏴‍☠️: ((0xf09f8fb4;0xe2808d;0xe298a0;0xefb88f);3 3 3 3) -- i.e. four codepoints, the first one advances the cursor two cells, the rest don't contribute. firefox deletes in two steps, first one (from the right) resulting in the black flag

16:24 <ovf> for readline i think i don't care either way, but it's amusing that it's precisely backwards

16:26 <rockorager> ovf: what are you trying to do?

16:29 <rockorager> firefox behaves the same for me, as does libreoffice and I'm shocked

16:29 <rockorager> They should delete the entire grapheme, IMO

16:32 <ovf> rockorager: trying to write a readline replacement that maintains its idea of character widths by querying the terminal

16:32 <rockorager> What language?

16:32 <ovf> i'm writing in k. does it matter?

16:33 <rockorager> only if you wanted me to recommend a library to use for unicode

16:35 <rockorager> ovf: https://0x0.st/8KtA.mp4

16:35 <rockorager> This one doesn't query the terminal except at startup

16:36 <rockorager> The idea is: terminals will either support mode 2027 and/or explicit width (this is new as of this week)

16:36 <rockorager> You query at startup for support for both. If they have it, you need to do grapheme segmentation + measurement per latest unicode

16:36 <rockorager> (or in the case of explicit width, whichever unicode you have)

16:37 <rockorager> Explicit width you emit a sequence like `\x1b]66;w=%d;%s\x1b\\`

16:37 <rockorager> Where %d is the width, %s is the grapheme

16:37 <rockorager> I only do this for graphemes with width > 1

17:19 <ovf> rockorager: very impressive!

17:25 <dnkl> rockorager: nice!

17:44 <rockorager> dnkl: this is pretty cool https://0x0.st/8KvF.png

17:45 <dnkl> hehe

17:46 <dnkl> probably not enough that I can claim ligature support in foot 🤣

17:52 <rockorager> foot is the first terminal with client side ligature support

17:52 <rockorager> it's a feature ;)

17:57 <rockorager> I'm becoming a huge fan of this explicit width extension

17:58 <rockorager> It enables things like rendering tabs at any size but it acts (even to the terminal) as a single glyph