[umanwizard]

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.

[gpderetta]

You can already put multi-column-wide non-ASCII characters in your source code, so the horse has left the barn already.

[umanwizard]

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.

[IshKebab]

But the compiler isn't forcing it on anyone?

[jcelerier]

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

[aseipp]

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.

[dzaima]

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.