Readit NewsLiterally no other text field in any UI behaves like this. I cannot fathom why Mozilla chose to both ship this "feature" AND remove the option to opt out of it.
Some users prefer it. And that's fine! But don't take away my god damn option and force it down my throat.
Unfortunately I know of no such emulators for Mac or Linux.
struct S { ... };
typedef int S;
I don't really think changing this in C would break all that much code, but it's definitely not backwards compatible.
It's written in ZIL, which has a somewhat Lispy feel (for a bit of background, see another post by Plotkin here: http://blog.zarfhome.com/2019/04/what-is-zil-anyway.html). Infocom's own internal documentation for ZIL is here: https://archive.org/details/Learning_ZIL_Steven_Eric_Meretzk....
It's described here: http://www.libpng.org/pub/png/libpng-manual.txt
So far it's... different? The tab handling is better, and I think I like having actual tabs in a mobile browser. I'm disappointed that the tab groups don't work as well as in Chrome. I like the link preview feature, in fact I could imagine all links opening like that by default (but that's not an option).
I don't find it all that customizable, that only seems to be true for the desktop version. For example, I can't get seem to rid of the history button (which is styled like a sidebar button despite opening full screen).
There is no reader mode. There are page actions, which let you apply all kinds of nonsensical CSS effects such as blur. But no reader mode. The built-in content blocker doesn't remove cosmetic annoyances as effectively as Ublock does, which makes me miss reader mode all the more.
There don't seem to be any add-ons.
Overall, not entirely convincing.
1. https://github.com/mozilla-mobile/fenix/issues/20012#issueco...
There is, but as far as I know it's not something you can manually toggle. On sites which Vivaldi deems can be shown in reader mode, you're prompted to switch to it. I don't know what criteria it uses to determine that.
It has to be enabled: Settings→Accessibility→Simplified view for web pages
They cannot be pre-empted, but they must also return quickly, or risk causing lots of problems (see https://erlang.org/doc/man/erl_nif.html for slightly more detail on what this means). As such you can't just write some big function in C to do number crunching.
The NIF documentation mentions some ways around the problem, but all of them take some effort, or have tradeoffs of some sort. I was really excited when “dirty” NIFs were introduced, which can tell the BEAM that they'll run for a while, thus appearing to allow for long-running NIFs with no extra work other than setting a flag. However, it turns out that the BEAM just spins up N threads for scheduling dirty NIFs, and if you have too many such NIFs, too bad, some won't get scheduled till the others have completed. In retrospect it should have been obvious that there couldn't be a silver bullet for this problem, because it really isn't easy.
Erlang may well be my favorite language, but as you imply, it's just not going to be the right approach for everything: in my experience, it's absolutely fantastic in its niche but that niche is quite small. I think that's fine, though. For me, where Erlang does make sense, its concurrency approach makes it unbeatable, and I'll live with the performance tradeoffs. It turns out that basically all the NIFs I've had to write were just to gain access to functionality that Erlang doesn't expose (e.g. network namespaces on Linux, which are supported now, but weren't when I needed them).
But by default it's very difficult on my eyes due to the low contrast, so to make it at all usable I make use of a Stylish script to fix the text color.
auto p = std::make_unique<int>(5);
auto q = std::move(p);
std::cout << *p << std::endl;