Hacker News Reader

Comment by topaz0 | Hacker News Reader

I can't remember the last time I used a non-ascii character in the terminal. I know that's not the case for everyone, and they deserve good terminals too, but it does mean that the criteria measured here have no relevance to my choice of a good terminal for me.

View on HN

Seems quite hard to avoid

- file management such as running "ls" where any filename has any non-ascii character such as a CJK or accented letter

- editing any text file in a terminal editor that isn't 100% ascii

- viewing/printing any data from any source, such as a log file/the web/'curl'ing something, where any language other than English or non-ascii character is used

- using various modern command line tools that insist on printing emojis in their output

> using various modern command line tools that insist on printing emojis in their output

Ugh. Unpopular opinion this but I personally find this practice repugnant. Same for when used in git commit messages, CI/CD task names and other such places. It just cheapens the quality of the product in my opinion

Graphical characters and symbols like ticks I’m fine with. I have no objection to people wanting to make the terminal pretty. But emojis in software feels like juvenile - like signing a formal letter with your gaming handle.

Emojis are useful as visual indicators, there's anything from flags to check marks in them.

They can be super helpful to decorate CLI output.

If it feels juvenile but is helpful (as in many cases is) good.

Sure, some CLIs may over do with rockets and such, but any tools can misused.

I want country codes not flags. And check marks do not require emoji.

Every emoji I saw in a terminal or Git commit message was worse than alternatives. This included emoji intended for information not fun. Color made them distracting when the wanted information was anything else. A monochrome font could not solve this because most emoji are too complex to display clearly at normal text sizes without color. They were cumbersome to grep. (Uncommon Unicode characters would have this problem also.) Many had unclear meanings.

Use emoji in your CLIs if you desire. But make them optional. Opt in ideally.

Unicode can be useful. The emoji subset generally are not.

IMO emojis have no business in any form of text. It just doesn't belong.

It would be different if I worked in chinese or hindi or something, or worked with other people who do. Also worth noting that even terminals that score badly on this benchmark handle most of the things you mention just fine (e.g. accented characters or check marks -- unicode that is well-behaved in terms of mapping a single code point to a single fixed width character). The places where the poorly ranked terminals lose points is mostly in pretty complicated cases that are far from what terminals were originally designed for. Also I have never encountered a command line tool that prints emoji -- and if I did, I would be annoyed.

Literally none of those is a situation I've ever encountered. I don't think it's as hard to avoid as you think.

All depends on what you're doing. When I worked in computational linguistics of languages that don't use ASCII (or European "accented" characters), I was very concerned with the display of non-ASCII Unicode scripts: Arabic, Devanagari, Thaana, Tamil, Chinese, even at one point Cambodian (which was extremely hard to render, even in XeLaTeX--it's improved since then). But at the moment, accented European characters are all I need.

Accented letters are easy under GNU/Linux or OBSD under X. Just launch:

    setxkbmap -us option ctrl:swapcaps -option compose:rwin

The first switch switches ctrl with caps lock (it helps your hands) and the last one maps the right Windows key (you can use menu key from laptop too with compose:menu) so you just type [ ' ] [ a ] and you'll get an á char.

Reply on news.ycombinator.com