On the one hand I feel like the #WARNING_SIGN is a welcome addition. On the other, I'm sensitive to the idea that it will be totally obnoxious if you need to grep/search for it in whatever tool you're using.
Was a little surprised to learn that the warning sign is generally considered an Emoji; I guess I don't think of it that way. Was even more surprised to learn that there is no great definition for what constitutes an Emoji. The term doesn't seem to have much meaning in Unicode. The warning sign - U+26A0 - goes all the way back to Unicode version 4.0 and is in the BMP, whereas most Emoji are in the SMP.
> Was even more surprised to learn that there is no great definition for what constitutes an Emoji. The term doesn't seem to have much meaning in Unicode
How will it output on my VT100 serial terminal? :P
Somewhat related fun fact, anyone can submit an emoji to the Unicode Consortium annually, submissions are actually open right now: https://unicode.org/emoji/proposals.html.
If you're using an OS that honors your font choices (i.e., not macOS), you can use a font like Symbola to provide emoji so that they're stylized, monochrome, and vectorized, rather than incongruous color bitmap images. That helps them play nice with terminal colorschemes and things like that.
I'm not aware of any emoji fonts like Symbola which provide a monospace typeface, though. That would be a great option.
By honoring font choices, do you mean the ability to overwrite emojis as well? I’ve never had issues using custom/nerd fonts, but it’s true that the emojis have stayed true to the Apple style so far.
Indeed. Emoji are just characters, rendered via some font just like any text character. On non-Apple operating systems, you can select emoji sets via font configuration.
You can do it on macOS as well, but you have to disable SIP and modify/replace the files for the Apple Color Emoji font, because some widely used GUI libs are hardcoded to use it.
Idr the situation on Windows except that emoji glyphs are inherited from your other font choices, if your chosen font includes emoji. But on Linux it's generally easy to configure certain font substitutions only for some groups of characters, like emoji.
Well, other than the fact that it's hard to search for, things should be kept as simple as possible to improve reliability/interoperability. Are you confident that multi-column-wide non-ASCII characters work reliably without causing rendering issues on every possible combination of terminal/shell/OS, including over SSH? I'm certainly not.
Of course you can. I'd argue you shouldn't, but that's beside the point. There is clearly a difference between people being able to do something, and the compiler forcing it on them.
How isn't it? It's setting it by default which is equivalent to forcing it for the huge majority of users who won't even know that such a thing as a flag to disable these emojis exists
They are quite easy to search for actually, because they are sparse and you tend to not get so many spurious results due hitting things that contain your query as a substring. Even then, the glyphs appear inline in the warning message, they are not the anchor, you could still just search for "warning:" like you or your editor have been doing for years. Every operating system comes with an emoji picker, it takes like 2 seconds to use. I'm not sympathetic, tbqh.
If anything, an emoji is easier to search for, as less things would be using it than a general "warning" (or whatever would make sense, as the emoji'd thing isn't the warning itself). Do have to get a copy from somewhere to search for though. It's also much easier to "visually" search for it.
At least in the blog there are a two spaces after the emoji so it can freely draw past its boundaries rightwards without colliding with anything for a good bit; and nothing to its right is used assuming monospace alignment. So at worst you just get a half-emoji.
