gudzpoz

Paywall-free link [pdf]: http://www.concatenation.org/futures/maxo_lo.pdf

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.

[1] https://www.keybr.com/

[2] https://colemakmods.github.io/ergonomic-mods/angle.html

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.

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).

> some editors display small flag on the cursor displaying current position direction

I was amazed to see IDEA/RustRover doing exactly this [1] when I added BIDI texts to my code to test things out.

[1] https://i.imgur.com/Qqlyqpc.png (image taken from IDEA issue tracker)

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.

[1] https://yhetil.org/emacs-devel/87bjuy3ric.fsf@gmail.com/

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.

[0] https://www.waterfox.com/blog/a-new-chapter-for-waterfox/

[1] https://news.ycombinator.com/item?id=37435511

Japanese blog entry: https://gongo.hatenablog.com/entry/2018/12/22/190540

The WeTab / Infinity team has responded to this [1] (in Chinese). Basically, they argue that:

- The Clean Master extension has long been sold, and the malicious updated was not pushed by them.

- The other two mentioned extensions are not at all malicious. They collect use info for extension opt-out-able features and analytics (using Google Analytics and Baidu Analytics).

- They are communicating with the extension stores to restore their extension.

Let's hope it's not an AI company making AI-generated accusations.

[1] https://mp.weixin.qq.com/s/E8YQLWZFM2J7r5DZNSl47w & https://www.v2ex.com/t/1176484

Previous discussion: https://news.ycombinator.com/item?id=13149705

Thank you! It would indeed require extra effort for me to notice issues like this, and it is very nice of you to have pointed it out!

Speaking of personal devices, I also have a dedicated key binding for en dashes “–” (because, well, I already have a whole tap layer for APL symbols, and it costs nothing to add one more). Since we're on HN, I believe many people here can easily do that if they wish to, so I too don't think en/em dashes are very telling, especially on HN.

(...and of course we have an xkcd for it: https://xkcd.com/3126/ )

Statements like this always feel a bit rude to me—as a Chinese, I use em dashes (in Chinese texts) on a daily basis and insert them in English texts when I see fit.

A bit of background: Em dashes “—” (or, very often, double em-dashes “——”) are to Chinese texts what hyphens “-” are to English texts. We use them in ranges “魯迅（1881－1936）”, in name concatenations “任－洛二氏溶液（Ringer-Locke solution）”, to express sounds “呜——”火车开动了, or `“Chouuuuuuuuu”, starts the train' in English, and in place of sentence breaks like this——just like em dashes in English texts. They are so commonly used that most Chinese input methods map Shift+- (i.e., underscores “_”) to double em-dashes. So, as a result, while I see many English people have to resort to weird sequences like “Alt + 0151” for an em-dash, a huge population in the world actually has no difficulty in using em-dashes. What a surprise!

As for this article, obviously it was translated from its Chinese version, so, yeah I don't see em-dashes as an AI indicator. And for the weird emoji “” (U+1F54A), I'm fairly certain that it comes from the Chinese idiom “放鸽子” (stand someone up, or, literally, release doves/pigeons), which has evolved into “鸽了” (pigeon'ed), a humorous way to say “delayed, sorry!”.

[0] https://zh.wikisource.org/wiki/标点符号用法

This clause is usually used together with the next sentence in the original poem:

> 先天下之忧而忧，后天下之乐而乐

> (put the world's worries before yours, and put your happiness after the world's) > edit: this translation is wrong, and raincole has a definitely better translation

Since the model is a language model, they probably use this to demonstrate the model's language capabilities – the model should be able to complete the whole sentence pair. The paper also mentions this:

> To ensure the model’s language capabilities, we introduced 10% of in-house text-only pretrain data.

So I believe it is just a text-only demonstration.

... That post you linked was from two years ago, discussing JEP 295, which was delivered eight years ago. Graal-based AOT has evolved a lot ever since. And the answer even explicitly recommended using native images:

> I think what you actually want to do, is to compile a native image of your program. This would include all the implications like garbage collection from the JVM into the executable.

And it is this "native image" that all the comments above in this thread have been discussing, not JEP 295. (And Graal-based AOT in native images does remove the need to bundle a whole JRE.)

Now we also have an xkcd for this:

> not chatgpt output—i'm just like this.

> https://xkcd.com/3126/ — Disclaimer

As someone based in China, it's a bit surprising that techniques used by Chinese people get very few mentions here, while I do think they are quite effective against access blocking, especially after coevolving with GFW for the past decade. While I do hope blocking in Indonesia won't get to GFW level, I will leave this here in case it helps.

I found this article [0] summarizing the history of censorship and anti-censorship measures in China, and I think it might be of help to you if the national censorship ever gets worse. As is shown in the article, access blocking in China can be categorized into several kinds: (sorted by severity)

1. DNS poisoning by intercepting DNS traffic. This can be easily mitigated by using a DOT/DOH DNS resolver.

2. Keyword-based HTTP traffic resetting. You are safe as long as you use HTTPS.

3. IP blocking/unencrypted SNI header checking. This will require the use of a VPN/proxy.

4. VPN blocking by recognizing traffic signatures. (VPNs with identifiable signatures include OpenVPN and WireGuard (and Tor and SSH forwards if you count those as VPNs), or basically any VPN that was designed without obfuscation in mind.) This really levels up the blocking: if the government don't block VPN access, then maybe any VPN provider will do; but if they do, you will have a harder time finding providers and configuring things.

5. Many other ways to detect and block obfuscated proxy traffic. It is the worse (that I'm aware of), but it will also cost the government a lot to pull off, so you probably don't need to worry about this. But if you do, maybe check out V2Ray, XRay, Trojan, Hysteria, NaiveProxy and many other obfuscated proxies.

But anyways, bypassing techniques always coevolve with the blocking measures. And many suggestions here by non-Indonesian (including mine!) might not be of help. My personal suggestion is to find a local tech community and see what techniques they are using, which could suit you better.

[0] https://danglingpointer.fun/posts/GFWHistory

> All JavaScript regexes engines that we could find, except one, use a backtracking implementation strategy [Chromium 2009; DukTape 2013; Hermes 2022; MuJS 2014; QuickJS 2020; WebKit 2018]. The exception is V8...

Well, maybe there's another: TRegex [1] in GraalJs [2].

[1] https://github.com/oracle/graal/tree/master/regex / https://epub.jku.at/urn:nbn:at:at-ubl:1-24940

[2] https://github.com/oracle/graaljs

I was writing from the aspect of an Lisp implementer, so that means it is not how I can just use vectors but about how existing code represents a sequence, and it is part of the job of the runtime to make it as fast as possible.

From what I see from existing ELisp code (at least in the Emacs codebase), the idiomatic representation of sequences (fixed-size or not) is using cons lists. And it is not surprising: Emacs vectors are fixed-size and that makes it very inflexible and only suitable for a few things. This matters because, for example, if you want Emacs to compete with VSCode in performance, you eventually compares how idiomatic code performs. Note that how cons lists affect performance in real-world ELisp code remains unknown because it is yet to be benchmarked, but exposing the internals of idiomatic lists as conses does pose some challenges for an implementer aiming for further optimizations.

So I've been writing a JIT runtime for a Lisp dialect [0] for a while and got into the habit of feeling jealous of other languages with array primitives, especially after I learned what you can do with arrays or opaque lists (see V8 element kinds [1] for an example). And then I discovered this article (or complaint?) by Xah Lee.

Aesthetically speaking, I quite like conses, in that it is powerful and flexible enough to hold both trees and lists. But performance-wise, I guess it's always the simplest things that are hard to optimize, and cons-style linked lists can't really compete with arrays [2], if you are aiming to get on par with V8.

However, I still believe that, with a JIT runtime, it is possible to have some Lisp lists backed by arrays and am working on it [3]. Currently, =setcdr= causes most trouble for me and I don't know if the additional checks are going to ruin the performance improvement brought by arrays. But if things go well, we might get to see what conses could have cost us.

[0] Emacs Lisp, in Java, with Graal Truffle

[1] https://v8.dev/blog/elements-kinds

[2] https://en.wikichip.org/wiki/pointer_chasing

[3] I am not aware of other Lisps doing this. Cdr-coding is the closest, but it is still a linked list (implicitly).

A use case: https://news.ycombinator.com/s.gif (43 bytes) (use for comment indentation)

An "JIT interpreter" for Emacs Lisp [1] with Graal Truffle [2] in Java. And it is really amazing how the frameworks these days simplify building a JIT runtime for a language. Currently I'm working on a pdump[3]-like feature for it.

[1] https://codeberg.org/gudzpoz/Juicemacs/src/branch/main/elisp

[2] https://www.graalvm.org/latest/graalvm-as-a-platform/languag...

[3] https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...

Personally, and contrary to the article, I do prefer Emacs's plain text widgets over more "GUI-like" ones. Plain text widgets minimize the differences between TUI and GUI Emacs and also inherently offer text selection, searching, copying, and pasting, which nicely integrates with Emacs. I mean, not many GUI frameworks let you place a cursor within a button and select its text, do they? I believe this is a unique advantage of text-based widgets: while other GUI applications require a dedicated mechanism for searching through their settings, text-based widgets allow you to use any text-searching packages to perform these actions.

Reading through the article, the author seems to be hoping for a pure GUI approach with Emacs-like navigation mechanisms, but I am not convinced that this can be as flexible as text-based widgets. However, for packages used exclusively within a GUI environment (like el-easydraw [1], which relies quite heavily on SVG-based widgets), it would be nice to have a dedicated GUI widget library.

(There was a discussion on Reddit about this a week ago [2], and I saw some comments defending GTK and PGTK that might be worth reading.)

[1] https://github.com/misohena/el-easydraw/

[2] https://www.reddit.com/r/emacs/comments/1kcgwme/the_emacs_wi...

Garuda Linux has been hosting their own Firefox Sync server for a while now for their FireDragon browser [1]:

   defaultPref("identity.sync.tokenserver.uri", "https://ffsync.garudalinux.org/token/1.0/sync/1.5"); // --> FIREDRAGON CONFIG

(They seem to be running the older non-Rust sync server though. [2])

[1] https://firedragon.garudalinux.org/

[2] https://gitlab.com/garuda-linux/infra-nix/-/blob/main/docker...

Speaking of advocating RSS, I was trying out Nikola [0] for static site generation and found that they have a really nice-looking RSS end-point [1] that is viewable both from the browser and an RSS reader. Looking into the XML, it turns out it's called xml-stylesheet:

    <?xml-stylesheet type="text/xsl" href="assets/xml/rss.xsl" media="all"?>

And I would argue that this is an excellent way to introduce new readers to RSS: instead of the browser popping up a download prompt, you can make your RSS feeds themselves a dedicated page for advocating RSS, in case an interested reader is browsing through the links on your site.

[0] https://getnikola.com/

[1] https://getnikola.com/rss.xml (Open it in your browser!)

[2] https://github.com/getnikola/nikola/blob/master/nikola/data/...

Quitlessia and NeoQuitlessia... These names are evil. (Doom Emacs lies in NeoQuitlessia instead of Emacsia, which surprisingly makes sense. :)

> Emojis are terrible

Not just emojis. Recently I've had some fun trying weird Unicode characters in different terminals (e.g. 𒐫):

- QTerminal/Konsole: Tofu

- Xfce terminal: Results in overlaps with characters that comes after it.

- Alacritty: Similar to Xfce terminal, but glitches when the cursor/glyph moves.

- COSMIC term: No overlapping glyphs, except that the line then wraps only after it grows out of screen.

- Kitty/WezTerm: Scales the glyph to fit it into a single column. (Barely legible.)

I don't even known what to expect. It is indeed a mess over there.

I once tried to use sql.js [1] on a static site for full text search. It worked, but the resulting database size for that site was too large for the web, even with things like detail=none and content='' applied, and requiring the user to download a database each time was just no go. (I guess things should work better for sites with less content or those not requiring a trigram tokenizer.)

I switched to Pagefind [2] afterwards before finding out a sql.js-httpvfs [3] fork of sql.js that removes exactly the need to fully download a database (with HTTP range requests). I haven't got the chance to test sql.js-httpvfs out though, but it looks pretty sound and could be much more flexible than Pagefind. (Previously discussed at https://news.ycombinator.com/item?id=27016630 .)

[1] https://github.com/sql-js/sql.js/

[2] https://pagefind.app/

[3] https://github.com/phiresky/sql.js-httpvfs

I've been wondering if these magical registry things are documented anywhere... Searching, for example, "site:microsoft.com DisableSearchBoxSuggestions", only leads me to tons of forum posts.

I would love a configuration system with centralized database and centralized documentation, but no OS currently seems to be able to achieve that, and Windows' missing documentation appears even worse than obscure but documented config files.