Option to opt out of CLI emoji via spago.yaml, env var, and/or flag

[toastal]

I appreciate the effort & whimsy put into selecting + supporting emojis, and I like them on websites & in chats, & I can get down with ASCII art or Kaomoji (｡•̀ᴗ-)✧ or general Unicode, I however find emoji in terminal output with its bright colors and solid fills distracting in the visual hierarchy for both TUI workflows & reading my logs; it’s too much. Emoji will also appear broken in TTYs, other environments, & cases where the system emoji doesn’t support the chose symbol.

Considering there’s a way to opt out of color, I would like to opt out of emoji.

Yarn v1 (JS) uses yarn --no-emojior in the RC file { ..., emoji: false }. Homebrew for macOS uses HOMEBREW_NO_EMOJI=1. Babel (JS) & Ember (JS) ended up removing their emoji support from CLI altogether.

[f-f]

The emojis are not for cuteness, but for clarity of display - I put them there to grab attention in key parts of the build, e.g. see here, they appear (1) when selecting the package to build and (2) when the build is done:

So the idea is exactly what you are mentioning, to get your attention while you read logs. I personally find they look great on my terminal, but YMMV as other OSs have different emoji packs.

This is all to say that while I'm not happy about adding yet another flag, I'm up for swapping them out if we find another way of grabbing attention in the same way.

I guess we could just disable them when --no-color is passed? This would solve the issue of them being broken on TTYs as well, since we default to no-color there.

[toastal]

Eh. These are separate issues. A terminal emulator can display colors just fine yet still have issues with the weird sizing of emoji—such as Kitty that, for performance, breaks the terminal into a grid based on the sizing of the configured monospace font which rarely aligns with dimensions of the emoji font. This also doesn’t address that while some folks find them helpful for getting a bearing on the output, others find them more distracting than helpful (color & indentation are already doing this). -- toastal ไข่ดาว | https://toast.al PGP: 7944 74b7 d236 dab9 c9ef e7f9 5cce 6f14 66d4 7c9e

[f-f]

The screenshot above is from Kitty FWIW

[toastal]

Also kitty:

[toastal]

…And moments later I ran into where things no longer line up. It’s supposed to be a single character.

[f-f]

Ah indeed that doesn't look good. The only emojis that we use are ❌ and ✅ and ⚠️, we can switch them out for equivalent Unicode symbols if we can find ones that approximate these well.

[toastal]

To be fair, these specific symbols aren’t half bad as they generally match your text color whereas some CLIs get way too heavy-handed to the point where significant time is spent forcing emoji since everything has to have an emoji now …which Spago isn’t doing. Unicode won’t run in the TTY still since it’s locked to ASCII :(, but an incomplete list of non-emoji Unicode options could be:

Checkmarks: ✓ ✔ Warnings: ⚠ ! ‼ Failures: 🕱 ✖ ⛌

[f-f]

Cool, we can go for ✔, ⚠ and ✖, and skip them if we are running with no-color (since TTY won't support that either)

[toastal]

In the TTY you will get a Unicode tofu block, but usually sans the the hex code inside it. You could argue that it could function as a bullet point of sorts which might make it clearer & then not have to concern yourself with an indentation change for no-color.

[fsoikin]

I found a bit of a problem with these non-emoji characters. For some reason, in Windows Terminal, they look like this:

Note how they smush into the text. This is not because I neglected to add a space. They actually require two spaces.

In fact, even if I just paste them in the command line they behave the same:

---

This appears to be an issue with the newer generation Windows UI, because they also look like this in the historic clipboard UI:

But they look normal in GNOME Terminal:

As well as in ConEmu, which uses Win32 UI:

I cannot verify on a Mac.

---

So this is only an issue for Windows, but I'm unsure what the official policy on this would be here.

[fsoikin]

Checking some of the other checkmark characters:

Windows Terminal:

GNOME Terminal:

ConEmu:

The only stable one appears to be \x2713 - "light checkmark".

[f-f]

Of course, Unicode joys 😄

I'd say let's try to find a set of characters that look good in Windows/Gnome, and I can test them on mac.

We can try using the 2713 checkmark, and other things that don't render weirdly. In case it still looks unreasonable we can special-case Windows of course.

[fsoikin]

A wide variety of crosses is available.

Windows Terminal:

GNOME Terminal:

ConEmu:

[fsoikin]

On "warning" signs, however, the choice is extremely limited.

Windows Terminal:

GNOME Terminal:

ConEmu:

[fsoikin]

We might also do ASCII art instead, like:

Or:

[f-f]

Thanks for collecting these - let's try to use 2713 for the checkmark, 2718 for the cross, and 26A0 for the warning sign.

I'd also say let's keep printing them even in monochrome mode, because Unicode support may be present even when opting out of color. Worst case one will get the unicode replacement block, which is alright.

[fsoikin]

The 26A0 character is essentially the same emoji I think. Or at least it has similar problems.

Windows Terminal:

GNOME:

ConEmu (note the shift):

What's the argument against ASCII art?

[f-f]

What's the argument against ASCII art?

The [v] looks confusing to me - the other ones are fine.

The 26A0 character is essentially the same emoji I think. Or at least it has similar problems.

Right. I think 203C is our next best bet. If that doesn't work I'm tempted to just stick with the emojis 😅

[fsoikin]

Done. 203C looks acceptable from my POV.