Lady, EVOLVED @Lady@cat.family

you can publish open source software without providing so much as an email contact, much less a listserv, forum, or other community space

i’ve committed code to this repo every month this year and i’m just waiting to see how long that goes on for

you ever just do something poorly the first time https://git.ladys.computer/Shushe/commit/550d6ccc74b1aae2f45947df47245fb57b111c2b

(original post wasn’t about Swift, but i was just thinking about it versus such languages as Zig and Rust which target much larger sets of platforms)

it does bother me that Swift isn’t more portable but i also understand that the reason Swift isn’t more portable is because it supports such advanced features as “Unicode”

and i would take “there are just multiple interoperable Swift implementations”; that would be better actually

which is more efficient:

• writing the software library once, making it portable across many platforms, and then dealing with the ensuing portability concerns for decades to come

• writing the software library multiple times

always bothered me that snickerdoodles don't contain snickers. snickersdoodles

i just wanted to file a bug 😩

so far from what i understand it’s working in spain but not on either side of the united states

did the united states government D·N·S block the gnome foundation

can other people resolve Any gnome.org domain or are they just down everywhere?

uhhhhh gnome.org u ok?

(the short version is that the cgi service runs as a different user than owns the repository, which git doesn’t allow anymore unless you specifically opt in via a global .gitconfig)

apparently at some point my git updated to break https fetching from my gitweb server; i’d apologize but 0 people have noticed and sent me an email about it so

anyway ⛩️📰 书社 <https://git.ladys.computer/Shushe> is BASICALLY 1.0.0, pending me actually putting together documentation for it, which will take a while because that means coming up with my own custom documentation language, because DocBook wasn’t good enough for me, and my website has been Wanting an update for some time so i might go take it for a pre·emptive spin

the distinction between emoji style and text style is like the distinction between upright and italic, the existence of variation selectors for some of the set NOTWITHSTANDING

give me the means to choose at the font level!!

the entire POINT is that whether a character has text or emoji presentation should be a quality of higher‐level markup and not encoded at the character level. variation selectors are a begrudging concession for use in limited scenarios where a plaintext distinction may never·the·less be argued for. but that whole conceptual framework doesn’t WORK when your higher‐level markup is just doing “implicitly insert characters into the text stream and then render as plaintext like normal”

of COURSE this would mean doing additional work, work which may right now be difficult or even impossible, to do font selection to ensure that only fonts which display emoji characters with text presentation are used, and not fonts which display emoji characters with emoji presentation. this is maybe impossible because i am not sure fonts STILL have a good understanding of what “emoji presentation” means nor operating systems fallback mechanisms for properly selecting the correct font for a given presentation. NEVER·THE·LESS

the current definition of `font-variant-emoji´ simply implicitly adds a V·S·15 or V·S·16 after emoji characters which can take them. this is definitely the least useful possible interpretation of `font-variant-emoji´. if i `font-variant-emoji: text´, i would like NO emoji characters to be given emoji presentation, not “only emoji characters which were not {already encoded codepoints at time of encoding and thus prone to possible awkward re·presentations in pre·existing encoded texts}”