You can try TeXmacs in your browser at https://yufeng-shen.github.io/Mogan.html . (It's actually from a fork of TeXmacs called Mogan, of which I've been a happy user due to better CJK support.)
By the way, I do think TeXmacs is an Emacsen as it provides Guile/Scheme as an extension language, though I don't know how customizable it is. (I think the built-in REPLs for Python/Maxima/Scheme/... are written in Scheme.) And then, it does support quite some TeX commands (and you input them by pressing backslash followed by their command name), so I do think their "TeXmacs" name is very much justified.
Unfortunately, many Qwerty typing guides group keys in left-leaning columns [1], requiring many to twist their left wrist. And this is why I hope the angle mod [2] from the Colemak community gets more mainstream recognition: instead of learning to twist your wrist, just shift the keys to let them adapt to you. This "un-kinks" the layout, allowing your left wrist to remain perfectly straight while your arm approaches the keyboard at a natural, relaxed angle like the person in the right side of the drawing.
Note that there are two measurement systems involved: first the camera, and then the human eyes. Your reasoning could be correct if there were only one: "the sensor is most sensitive to green light, so less sensor area is needed".
But it is not the case, we are first measuring with cameras, and then presenting the image to human eyes. Being more sensitive to a colour means that the same measurement error will lead to more observable artifacts. So to maximize visual authenticity, the best we can do is to make our cameras as sensitive to green light (relatively) as human eyes.
Oh you are right! I’m so dumb! Of course it is the camera. To have the camera have the same sensitivity, we need more green pixels! I had my neurons off.
Thanks.
An example: the text "Hello There إلا بسم الله Beep Boop!!" should turn into two visual lines as follows if it is line-wrapped:
Hello There إلا
بسم الله Beep Boop!!
Notice how "إلا" goes from the fifth word (from left to right) to the third after the line wrap. This won't work if shaping happens before line wrapping.
Nitpicking your nitpicking: I think the author meant better.
The "ae" example was used as an introductory example for us English readers.
Unlike the Arabic examples where ligatures are mandatory and supported by most
Arabic fonts, not many English fonts have an "ae" ligature these days. Not to
mention this is a web page and a user can freely apply their !important font
styles.
Using æ to mean "treat it as an 'ae' rendered by ligature which is
visually indistinguishable" does not mean the author knows nothing about this
(although the wording can use some improvement to reduce the ambiguity).
I don't understand: æ is not a ligature so it's not an example of a ligature. There are English ligatures to use.
Also, most fonts have many characters beyond ASCII, including æ. If your font lacked it then you would see an empty box, not the two letters ae. Applying a font style would not change the rendering of æ into ASCII letters; I don't think it changes the rendering of English ligatures, which are separate code points in Unicode.
I saw that headerless cons patch too! [1] It's quite exciting to see what a customizable GC is able to do, and I agree a GC with targeted object types (combined with tagged pointers) have quite some room for optimization compared to generic GCs in JVM.
Your cursory search likely provided outdated info. [0] Quoting from it's maintainer: [1]
Waterfox is independent again: [0]
And System1 are an “ad-tech” company but the term should be used loosely. The ownership made sense as they are a search engine aggregator and they own a bunch of old school search engines like DogPile, InfoSpace etc. Nothing to do with what people associate ad-tech with, i.e. tracking you across the web or collecting personal data.
