03:14 <baltazar> dnkl: note: you don't need to bump pkgver in -git aur packages, and in this case it won't even work as it always builds the master branch (but 1.20.2 is not on it)

11:26 <ovf> exploring the wonderful world of terminal programming, i'm trying to implement a line editor that always has the same idea of text width as the terminal. as a first approximation, i can keep asking for current cursor position with dsr (csi 6 n) and maintain a mapping. however, i don't understand foot's (and presumably others) approach to double-size unicode stuff, like 🏴‍☠️ (which foot renders as a single pirate flag)

11:28 <ovf> it's probably a tired debate at this point, but i can't figure out even the conceptual behaviour of my editor+foot, given that this thing is taking two cells (or one double-size cell? how do i even ask the terminal about that?)

11:33 <dnkl> you can't ask the terminal. your only option right now is to print the character and then check the cursor position

11:34 <dnkl> fwiw, foot uses utf8proc to determine character widths, meaning it's Unicode compliant. So in theory all you need to do is to ensure you're compliant as well

11:35 <dnkl> there's one quirk though; all functions I'm aware of, that measures width, don't handle grapheme clusters correctly (i.e single glyphs consisting of multiple code points). By default, foot always assigns such glyphs the width 2

11:47 <ovf> yes, 'print and check' is what i'm doing. the basic idea is just to always do whatever the terminal does (because other things like gnu readline try to second guess and come out wrong, due to the different implementation decisions, or quirks as you call them)

11:48 <ovf> but still i think that doesn't tell me what a backspace/^h should do after a grapheme cluster (again, i think i don't care about unicode correctness -- it's the terminal's job -- i just want to be kept in sync with it)

11:49 <ovf> of course in the ideal world, any terminal would have an 'edit line' mode and a line editor wouldn't be needed. :-)

11:49 <dnkl> from the terminal perspective, a backspace just moves the cursor. It's up to you what to do in response to a backspace key press. I would move it two cells back, on case of a double width glyph

11:55 <ovf> except that there's no way to know foot thought it was a double width glyph, right? the pirate flag is especially treacherous because its first codepoint is a normal glyph, so at this point foot will move one cell to the right. the next two codepoints result in that glyph becoming a double-width one, so to me doing 'print and check' this looks indistinguishable from a normal two-glyph string?

11:57 <dnkl> yes, you can't check the cursor after each byte written, but after each grapheme cluster written. that means you have to be "Unicode aware", and parse grapheme breakpoints etc

11:58 <ovf> which pretty much defeats the point of the exercise, i guess, because different terminals will behave differently here, and my editor basically has to reimplement the relevant logic from each one of them

11:59 <dnkl> there's an escape implemented by a few modern terminals that indicate whether they do proper Unicode processing

11:59 <dnkl> terminals that don't implement that particular escape should still reply to a query for it

12:03 <ovf> thanks! does foot do it?

12:05 <ovf> btw on the foot side, i guess the only way to know the actual width of unicode text is to ask your shaper (harfbuzz via fcft in your case?). whenever i see those blog posts comparing the string length functions in various languages, i always wonder why nobody suggested defining one based on shaped text. :-)

12:07 <ovf> i see you have actually written out most of what we've discussed above in the changelog entry for 1.8.0 (with the max-two change having landed in 1.8.1)

12:24 <dnkl> ovf: yes, foot "does it", including implementing the query escape. on the phone right now, don't remember the exact escape...

13:20 <rockorager> It's private mode 2027

13:27 <rockorager> ovf: generally you'll want a unicode library that tells you the monospace width of a string. You can calculate this yourself if you only can get it for a single codepoint too, but you still need to segment by graphemes so you can find things like emoji modifiers

13:27 <rockorager> If a terminal supports mode 2027, turn it on and use the result of that library as the width

13:29 <rockorager> If it doesnt, the terminal will instead calculate the width based only on the individual codepoints (ie, just segment by codepoints and each codepoint has a width)

13:29 <rockorager> There is one exception: kitty has mid-tier support - it gets everythign right except if there is a ZWJ, in which case it ignores the ZWJ

13:31 <rockorager> So kitty will get things like the country flags correct, but pirate flags wrong

13:42 <cbb> there is no "wrong" when it comes to ZWJ sequences is there?

13:42 <cbb> aren't they all "reccomendations" rather than standard?

13:43 <cbb> and it's legal to define implementation-specific ones, that terminal client apps have no good way of discovering

13:44 <rockorager> I thing Unicode literally says a zero width joiner combines the preceding and next codepoint into a single glyph, meaning the size doesn’t increase

13:44 <rockorager> But yeah the fallback says that you could so it decomposed too

13:45 <cbb> https://www.unicode.org/reports/tr51/#Emoji_ZWJ_Sequences

13:46 <cbb> there's no good way for a client to know which will be used though

13:47 <cbb> other than the list of recommended sequences

13:48 <cbb> i.e. this: https://www.unicode.org/emoji/charts/emoji-zwj-sequences.html

14:53 <cbb> I didn't mention that to nitpick btw... I'm just quite interested to hear other people's thoughts on that subject

16:50 <rptbunny> Hello. Just upgraded from older version of foot to 1.20.1 and trying to replace my notify command; what would be the equivalent of `notify=notify-send -a ${app-id} -i ${app-id} ${title} ${body}` for the new `desktop-notifications.command`?

16:51 <rockorager> make a new section called [desktop-notifications], then put that line under it, but as `command=` instead of `notify=`

16:51 <rptbunny> I'm stupid. Thanks.

16:53 <rptbunny> I was thinking "what in the world am I supposed to do with this OSC 777 stuff", reading foot-ctlseqs(7)