In what way is it crippled?

Takes forever to load anything

Not for every YouTube Premium subscriber in populated areas of California with decent internet connections watching popular videos, even with a userscript automatically selecting highest quality. Always instant, zero wait, very few exceptions.

It’s non-Google sites where Firefox may not be as well supported as Chrome, IME.

I use YouTube on Firefox (with uBlock Origin) almost exclusively and this has not been my experience.

That's exactly the "dependency cooldowns" we have right now that the author argues against.

To visually compare characters you need to map them to glyphs; what is the glyphset and how much of Unicode does it actually cover?

The only way that I can think of to respond to that question is this: https://charcuterie.elastiq.ch/data/fonts/fonts.css

It only seems to work for some subset of CJK characters. I haven't been able to figure out why some work and some don't.

For instance 叱 and 明 both seem to fail in the same way: U+1F996 T-REX in the upper left corner and the URL fragment fails to update.

That’s great for you. Isn’t feasible for software development by teams that are native in a language with a non-Latin script.

Do you write the code itself in a language other than English? Localizations typically are in different files.

I do see a handful of people using non-ASCII identifiers in their code, but that's rare. Much more common is explanatory comments, docstrings, etc. in the local language. To require those to be ASCII would be a non-starter.

> If, in the context of cooperating together, you say "should I go ahead?" and they just say "no" with nothing else, most people would not interpret that as "don't go ahead".

wat

> The "why" is kinda sketchy

It seems pretty clear that the "why" is "because it's there"

> because it’s fun

Sounds good enough for me

How is the author the problem? What is the problem, in your view?

Creator of Orgro here.

> they only support a tiny subset of the format

I think Orgro's parser[0] is pretty complete at this point. If you can find an Org syntax that Orgro doesn't support, please let me know.

However I should be very clear here:

> they can't support any of the features that require the rest of emacs to be present which is a lot of of the value

This is absolutely true and unlikely to change anytime soon. As I'm sure you know, parsing the syntax correctly is not at all the same as supporting all of the features built on top of the AST.

[0]: https://github.com/amake/org_parser

This is the modern-day equivalent of asking the genie from the magic lamp for something, and getting something else that meets the letter but not the spirit of the request.

The smart thing to do is realize you don't know what you're doing, and don't rely on the genie at all. Or hire someone who knows how to tame the genie. Or whatever; someone else put it better: you fucked around and you found out. lol