Can your terminal do emojis? How big?

Technical causes of emoji/rendering bugs

• Core issue: mismatch between Unicode concepts (codepoints, grapheme clusters) and what terminals actually lay out (fixed-width “cells”).
• Many emoji are sequences (ZWJ, variation selectors, skin tones, families) that form one visual glyph but multiple codepoints. Terminals often just run wcwidth per codepoint and guess.
• wcwidth only returns 0/1/2 per codepoint; wcswidth is limited and bad at partial errors. Fonts and shaping engines can turn sequences into 1+ glyphs of varying width, independent of East Asian width metadata.
• Fonts themselves are inconsistent: some “narrow” characters (e.g., playing cards, alembic + variation selectors) are drawn 1.5–2 cells wide; emoji width may change with font choice.
• Correct behavior requires grapheme-aware rendering plus cooperation with the font/shaping engine; most terminals and TUI libraries don’t do this, leading to cursor desync, broken readline/editing, and weird wrap/backspace behavior.

Escape sequences, standards, and terminal differences

• Double-height/double-width text is old DEC VT100-era tech (DECDHL/DECDWL). Some modern terminals implement it; others ignore it or scale bitmaps crudely.
• Kitty introduces a custom “modern” scaling protocol (arbitrary scale factors, better feature detection). Some see this as useful; others view it as needless reinvention versus widely implemented DEC codes.
• ECMA-48 explicitly allows ignoring unknown escape sequences, so behavior diverges widely. Feature detection is hard, and multiple proprietary image/size protocols worsen fragmentation.

Use cases vs. drawbacks of emoji in CLIs

• Pro-emoji: good as high-salience status markers (ticks/crosses, traffic-light icons, git-status in prompts), more legible than plain words from a distance, survive piping/logging better than ANSI colors.
• Anti-emoji: terminals are often broken for emoji width; they clutter logs, break greppability, and frequently render incorrectly. Many prefer colors or ASCII art only. Suggested compromise: optional “fancy” mode or env flag.

Aesthetics, accessibility, and visual hierarchy

• Several commenters find full-color emoji in terminals/READMEs/code visually noisy, “chatty,” and distracting, especially for dyslexic/ADHD users.
• Argument from visual design: emoji are high in visual hierarchy (complex, colorful mini-images) and dominate surrounding text, especially in multiplexers or long scrollback. Overuse adds cognitive load.
• Some prefer monochrome emoji fonts (e.g., Noto-style outlines) or forcing text-presentation variants; others would avoid emoji entirely and stick to emoticons.

Broader Unicode and historical notes

• Grapheme cluster handling is seen as conceptually simple but maintenance-heavy because Unicode keeps evolving, especially with emoji.
• Debate over whether Unicode should have standardized emoji at all, retroactively changed default presentations, and made text effectively stateful via combining characters and joiners.