goranmoomin

A bit more minified/modern version of this that I'm using:

    function $e(t='div',p={},c=[]){
      let el=document.createElement(t);
      Object.assign(el,p);
      el.append(...c);
      return el;
    }
    
    var $t=document.createTextNode.bind(document);

That's 173 bytes not minified, might be useful for someone.

Interestingly, the function names are exactly the same - I guess people think similarly :-)

Hello, Seoul resident here — AMA!

It’s always surprising when you see our city’s name in HN...

Looks like the TLDR is that LA only has subways in downtown (I can’t understand the reason... why would people use subways then?), they should fix them. Looks like it strongly correlates with the car-centric culture of the US...

> We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools.

I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for.

> There are no pull requests or merge requests.

If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?

Hmm, that’s strange because I mostly find the ability to open websites in-app very useful: The context of how I was directed to the website exists in the app. I feel that if the site I’d moved to Safari, I eventually forget how I got to this site.

I think the problem isn’t in the WebView model - It’s probably that you have to use the browser to do something useful that WebViews can’t.

This post… probably doesn’t really mean anything.

Firstly, judging a web browser’s compelxity by judging the spec catalogue is already unfair. The catalogue is basically a dump of things related to the web, for example the specs of JSON-LD. (Which probably has almost no relationship to implementing web browsers, since that’s just a data format of JSON.)

Also, word count doesn’t correlate with complexity. That’s like…. saying that a movie will be more entertaining than another one because it’s runtime is longer. Web-related specs are much, much more detailed than POSIX-specs because of their cross-platform nature: we’ve already seen what happens if web-related specs look like POSIX: anybody remember trying to make web pages that work both in IE, Safari, Firefox in the early 2000s? (Or, just try to make a shell script that works on both macOS, FreeBSD, Ubuntu, and Fedora without trying out on all four OSes. Can you make one with confidence?)

Really, it’s just tiring to hear the complaints about web browsers on HN, especially the ones about ‘It wasn’t like it in the 90s, why is every site bloated and complex? Do we really need SPAs?’ Things are there for a reason, and while I agree that not every web-API is useful (and some are harmful), one should not dismiss everything as ‘bloat’ or ‘useless complexity’.

> HVIF does have level-of-detail hinting

Yeah, the Icon-O-Matic application documentation[0] has some more info on this.

From the site:

> With the LOD you control the visibility of a shape depending on its size.

> That way, you can leave away details of an icon that look good on a bigger icon, but maybe not so much on its smaller version.

> The LOD is not only for leaving out detailing shapes, but also to e.g. change the stroke width at different sizes, if you feel that's needed.

> Simply duplicate a shape, make your changes and set both of their LOD settings to show either one or the other.

Looks like somewhat similar to CSS media queries.

Edit: Looks like[1] SVG has a similar feature too.

[0] https://www.haiku-os.org/docs/userguide/en/applications/icon...

[1] https://twitter.com/tzmartin/status/688950091063771137

A TLDR from the past discussion[0] for the tour[1] based on my understanding (please fix me if I’m wrong):

Unison is a functional language that treats a codebase as an content addressable database[2] where every ‘content’ is an definition. In Unison, the ‘codebase’ is a somewhat abstract concept (unlike other languages where a codebase is a set of files) where you can inject definitions, somewhat similar to a Lisp image.

One can think of a program as a graph where every node is a definition and a definition’s content can refer to other definitions. Unison content-addresses each node and aliases the address to a human-readable name.

This means you can replace a name with another definition, and since Unison knows the node a human-readable name is aliased to, you can exactly find every name’s use and replace them to another node. In practice I think this means very easy refactoring unlike today’s programming languages where it’s hard to find every use of an identifier.

I’m not sure how this can benefit in practical ways, but the concept itself is pretty interesting to see. I would like to see a better way to share a Unison codebase though, as it currently is only shareable in a format that resembles a .git folder (as git also is another CAS).

[0]: https://news.ycombinator.com/item?id=22010510

[1]: https://www.unisonweb.org/docs/tour

[2]: https://en.wikipedia.org/wiki/Content-addressable_storage

I’m not a Go user, so I’m not a bit of the target audience, but it’s so refreshing that it has the native UI on macOS. Today deceloper tooling is almost all electron/Qt/custom-framework based cross-platform; I was really disappointed when I tried to find a decent editor with autocomplete (based on LSP), project management with a cocoa-based UI (like native tabs and cocoa textfields) and found... nothing.

It was really disappointing to find that nobody developing the developer tools really consider user experience or nativeness... even on the mac where Cocoa is very emphasized by the users. (For more of my arguments about native UI, see my comment against flutter: https://news.ycombinator.com/item?id=20612195)

This product with some C/Rust/Lisp support would be the product I would have to like to find, and I’m really looking forward to this product with the expectation where this might be more configurable or some other language support is added.

Great job for the developer, I really is thankful for showing that a cocoa-oriented editor is possible & feasible. Thanks.

> That input methods are useless for me, because I know zero CJK characters, does not mean I think they are useless to everybody or Linux in general.

Yeah, but every app would 'just work' if we have a level of indirection with an IME by default, even for languages with Latin characters.

I mean, there is a reason why Windows & macOS all selects a similar architecture on text inputting.

> Right, I prefer slim systems and I typically uninstall everything input method related that my distro has chosen to preinstall. I cannot read or memorize a single CJK character, so why would I need that.

Yes, I'm exactly talking about this mindset. This is basically why Linux has such poor input method support. Because English has a special privilege of not needing input methods to be input in, combined with the fact that the majority of Linux application programmers use English only, that means basically all apps that don't consider i18n seriously are by default 'wrong', opposed to apps running on Windows/macOS which are by default 'right'.

> Basically I use my mother tongue (and a couple of other European languages I speak) only in Email, chat or maybe some web form.

Does that mean European languages are able to being input without special input methods?

> I can feel your pain though, because 10+ years ago we had the same problem with the couple of non-ASCII characters you need in most European languages.

The non-ASCII characters fit in the character array model that most western people think in, and as a plus they are fittable in the upper half of ASCII.

Asian CJK languages require a different model from the western ones.

> In order to have the situation in Linux improve there just need to be enough CJK contributors to fix existing bugs.

It's a failing fight. That only works on an ideal world where every program has enough contributors. Thats not true.

> This is more than programmer convenience, this is about system simplicity, absolute correctness (too many bugs because of unicode and complex layouting) and above all about _forcing_ people to use said lingua franca to become comfortable speaking it.

The reason the writing system in computers are simple is because the latin characters are simple, and the majority of early computer users (which the majority of was English speakers) didn't feel the need of sophisticated systems.

I (often) find that complexity that is inside the western culture is warranted, while complexity not in western culture is not.

While not a great analogy, think of TTS. English TTS is (at least from what I have heard) not that easy (encodable in logic, but not as simple as mapping characters to audio). That resulted in some sophisticated TTS systems, where it can handle lots of different phonetic structures.

Compare this to Hangul (the Korean character system) where every character is composed of several mini-characters which have a unique mapping to audio. Basically for a minimal viable product you can just convert text to decomposed format(NFD) and map the char points to audio.

Now, let's say that some company (an arbitrary choice, Facebook) decided to make a global TTS product, first in Korea. They just decided to map the char points to audio and post-process the audio. This TTS architecture obviously can't handle English without some major architecture changes. Then Facebook decides, this is a problem in English where the phonetic structure is unnecessarily complex, and won't provide TTS service to English users.

This is something similar to what CJK users face, that people just won't make products that work reliably with CJK.

> What I'd do is switch to english language instead.

Hmm, I've never encountered situations when only English keyboard is available for communication (except for when someone is setting up a new Linux machine).

But even if there is such situation, I don't think that would happen, I'm not sure if Swedish is similar to English but English is cognitive load here. Even with people that are proficient in English, I cannot imagine myself communicating with the English language.

I remember myself resorting to online keyboards though(while setting up Linux).

> I've been saying that all text input should go through OS-level IMEs

This is so true, all commercial OSes that take i18n seriously do this, while most open source OSes' community (which communication revolves around English) decided that IMEs are an add-on for CJK people.

It's a pity, and this one reason is enough for Linux to be never adopted for ordinary users in the non-western world.

> Do kids that speak english communicate more in english in cases where the input doesn't let them communicate easily using their preferred script?

As the input method of CJK languages are significantly different from English (compared to the relatively small difference), every app just allows the locale's input method.

Nobody tries to communicates with only the English keyboard, b.c that is outright impossible (while in Swedish it's possible in worst cases).

> I think it would have been better to have every body just learn english as their second (computer usage) language.

Hmm... it might not be well known to the western world, but AFAIK most parts of the world learns English as their second language. At least East Asia learns English pervasively throughout your life. We start learning English when we're five.

But still, English is not the only language, and we want to communicate with other people. Just that people can use English doesn't mean they prefer English & Latin characters to communicate. You can't just er... force people use Latin characters for the sake of programmers' comfort. Will you use your terminal if the terminal demands you to press space & backspace everytime when you're typing in English characters?

> While spending a lot of time with monospace fonts and mostly ASCII characters (programming and writing, terminal emulators, IRC/mail/MUDs/feeds in Emacs) and working on a hobby project involving text rendering and selection (with potentially proportional fonts and Unicode), I keep wondering whether it's even worth all the trouble.

Yeah... and that's why FireFox & Eclipse still doesn't get CJK character input right. The percentage of people that must use characters not included in ASCII is much bigger than people who do. It is worth the trouble, please consider users outside of the US & England.

As a person living with the CJK languages (I’m specifically a Korean), I find that some of these problems are prominent, even in the 21th century.

There are an excessive amount of programs that conflate key presses & text input, and ones that don’t consider input methods.

I use macOS & Linux, and while the default text handling system called Cocoa Text System in macOS handles input methods well, almost all applications that implement it’s own, like big apps like Eclipse and Firefox, don’t get this right.

On Linux, it’s terrifying; I’ve never seen any app that allows input systems to work naturally, and after a week of use you get used to pressing space & backspace after finishing every Hangul word. The Unix-style composability they want (apps should work whether or not input methods are used - and looks like Linux users that use Latin characters don’t use any input methods (opposed to macOS where Latin characters are input by a Latin input system), so looks like this state will persist.

About the emoticons, I’m not that concerned with that since most (if not all) users won’t really input the color modifier separately (or even encounter files that have a separate one), so you can just select a sensible behavior like the #2 or 3 or 4. Users who understand the color modifiers, and other Unicode fiasco will understand what is happening under the hood, and ones that don’t will just think the file is broken and none of the behaviors will make sense, whatever you do.

Well, as a Korean, I think that this is due to the difference of importance of how other people think me. I've heard that the western world is very individualistic, and people in general don't care much about how other people acts.

In Korea (and AFAIK Japan too), people very care of what other people think about them. They consider the consequences of every action carefully. One of the results is that people generally don't litter in front of other people, and that makes the city clean. The places without much people, they are dirtier than others because there aren't other people around them.

> I suppose you use it for servers and you don't deploy SBCL to end-user machines?

AFAIK, most Common Lisp applications are deployed in a single binary, bundled with the lisp implementation. SBCL isn’t an exception, so if someone would deploy an SBCL app to end-users, one would build a self-contained application with the `sb-ext:save-lisp-and-die` function [0].

[0]: https://lispcookbook.github.io/cl-cookbook/scripting.html

While I fully appreciate & support the structured shell approach (I believe it’s the future), I wish the efforts in making a mew shell should be more directed to a small selection of projects.

elvish[0], uxy[1], ngs[2] and basically all shell projects that allow other languages(e.g. python: tako[3], racket: rash[4] janet: janetsh[5]) are all similar attempts; and there are numerous more alternative (non-structured) shells like fish[6], and a whole lot more.

As a daily user of fish and a person hyped by elvish (but not using it as a daily driver :-(), I hope some structured shells get at least some traction, but there are too much approaches.

Well, I didn’t start as a rant but it became one anyway.

[0]: https://elv.sh/

[1]: https://github.com/sustrik/uxy

[2]: https://github.com/ngs-lang/ngs

[3]: https://takoshell.org/

[4]: https://rash-lang.org/

[5]: https://github.com/andrewchambers/janetsh

[6]: https://fishshell.com/