Handling of Emoji without a Text or Graphical Selector on Linux and macOS

[mwolson]

Hi,

Here's an example of what the default fallback emoji font looks like on Arch Linux with a wttr.in weather emoji:

Here's what it looks like when I add a second font-family line for font-family = Noto Color Emoji :

If it's agreed upon to change this for Linux only (the macOS default fallback font looks great here), I would probably have time to contribute a PR.

Here's the text in the screenshot just in case it's helpful:

🌨  27°F ↑13mph

[mitchellh]

That codepoint is U+1F328 which according to Unicode 15 (and 16) is default text presentation. You'll have to add a variation selector to it to force emoji presentation. U+FE0F. This produces a proper color emoji for me on Ghostty.

[mwolson]

While reviewing https://mitchellh.com/writing/grapheme-clusters-in-terminals , interestingly enough, both Emacs and Ghostty aren't able to just paste in the emoji mentioned there and display it correctly on a zsh commandline (nor is GitHub web UI taking it as a single emoji, displays two instead). Though if I ignore the UI representation on the commanline and just echo it into a file, and then cat the file, ghostty displays the character correctly in the output from cat, and Emacs (installed from emacs-wayland) can view it when opening an existing file.

[mitchellh]

That’s because zsh doesn’t support graphemes either. You have to use something like cat which just outputs bytes for it to be handled properly. Anything in the middle that mangles it will probably break. (FWIW, none of the major mainstream shells support this yet either)

[mwolson]

I see harfbuzz mentioned there as well, Emacs uses that now: (frame-parameter nil 'font-backend) returns 'ftcrhb on my Arch machine which matches that: https://www.gnu.org/software/emacs/manual/html_node/elisp/Font-and-Color-Parameters.html

[mwolson]

Ah I see, if the shell doesn't support it, that explains.

[mwolson]

It looks like you're right in that the codepoint doesn't have emoji_presentation. So it might come down to the preface of section 4 where they call out user expectations in several contexts like chat and word processing, both of which I've done in a terminal as it's kinda general purpose.

[mwolson]

I've made an attempt to distill the discussion a bit in case it's helpful, after reviewing the codebase just a bit. I've added a few minor findings from trying out different situations. I unmarked the previous answer one time only just in case it helps to track the discussion.

References

Section 4 preface: https://www.unicode.org/reports/tr51/tr51-23.html#Presentation_Style

• Key phrases:
  • While this is all perfectly legitimate for Unicode characters -- presentation style is never guaranteed -- a shared sense among developers of when to use emoji presentation by default is important, so that there are fewer unexpected or jarring presentations. Implementations need to know what the generally expected default presentation is, to promote interoperability across platforms and applications.
  • The presentation of a given emoji character depends on the environment, whether or not there is an emoji or text presentation selector, and the default presentation style (emoji versus text). In informal environments like texting and chats, it is more appropriate for most emoji characters to appear with a colorful emoji presentation, and only get a text presentation with a text presentation selector. Conversely, in formal environments such as word processing, it is generally better for emoji characters to appear with a text presentation, and only get the colorful emoji presentation with the emoji presentation selector.
• Table at the end of the Section 4 preface with recommendations on how to interpret the selector for different kinds of apps: https://www.unicode.org/reports/tr51/tr51-23.html#Emoji_vs_Text_Display
• Observation 1: Depending on the kind of application, the table indicates that not only the default representation may change, but even a provided selector may be ignored.
• Observation 2: The choice of what to use is fairly subjective, rather than prescriptive, and the recommendations seem to be largely trying to surprise the user the least, especially when using multiple different apps

Other Apps

• Generally will always show the color emoji, even when text presentation is requested on a selector
• Could be a deliberate choice, but more likely that most apps just haven't implemented the selector yet. Case in point - Emacs not even showing the text representation selector when asked to describe the character at point, but will show the emoji representation selector.
• When given an invalid emoji selector, will ignore it and render the emoji in color.

Ghostty on Linux

Default emoji with neither text nor graphics selector:

• Main point under discussion: Currently is rendered exactly according to the recommendations in Annex A: https://www.unicode.org/reports/tr51/tr51-23.html#Emoji_Properties_and_Data_Files .
• For example, if the emoji lacks Emoji_Presentation=Yes in the table, the emoji_text embedded font is selected, a variation of Noto without colors.
• The embedded font is always lower priority than user-provided font-family configuration lines, which lets my local workaround of providing an emoji in font-family succeed in forcing those kind of emoji to be rendered in color.

Emoji with text selector:

• Currently is always rendered without color
• On a fresh start: this actually ignores the user-provided emoji font-family and always uses the embedded font
• Probable bug: On doing this sequence of events while already started: (1) comment out emoji font-family line, (2) reload config, (3) uncomment emoji font-family line, (4) reload config -- the emoji will now fail to be rendered. The main font-family is "FiraMono Nerd Font" and the emoji font family is "Noto Color Emoji" in case there's something about either of those fonts which triggers it.

Emoji with emoji graphic selector:

• Is always rendered with color

Emoji with invalid selector:

• Possible bug: Will not render the emoji.

Ghostty on macOS

Default emoji with neither text nor graphics selector:

• Possible enhancement if other behavior desired: Always renders in color.
• Default emoji fonts aren't embedded / used on macOS.
• I thought that one of my prior fonts used to show that as uncolored, would have been "GeistMono Nerd Font" most likely, but haven't re-checked in a while.

Emoji with text selector:

• Possible bug: Never rendered.

Emoji with emoji graphic selector:

• Same as Linux behavior.

Emoji with invalid selector:

• Same as Linux behavior.

My Thoughts

• As a prior user of other terminal apps, it was surprising to do curl -f -s https://wttr.in/?format=2 and not see color emoji for weather like I do in those other apps.
  • It's also surprising considering that my editor and Chromium-based browser (when pointed at a saved file:// link) always show that emoji in color, even if it has a text representation selector.
  • The browser in particular was called out in the unicode.org table in Section 4 as something which probably should show a text selector when one is explicitly provided
• It's certainly possible that Ghostty is a first-mover on the new unicode.org recommendations and most other apps are lagging behind
  • Example: new graphene width proposal
  • If this is the case, a right move may be to preserve the current behavior on Linux and wait for other apps/vendors to follow suit and implement default behavior this way
• Other factors:
  • Target audience for Ghostty: will Ghostty tend to attract people who use emojis for chat or (in my case) tmux window decoration?
  • Ghostty's use of the colorful emoji in other contexts like the title bar when browsing themes, and the landing page of the website could bias user expectations a certain way
  • Would it even be surprising if someone does obtain a text selector emoji from some other website or app which renders it in color there, and then doesn't render in color in Linux Ghostty, and/or doesn't render in macOS?
  • Consistency between macOS and Linux in the near vs. far term; would Apple be likely to change the default from "always in color" to "some in color, some not" and add colorless options to their emoji font?

[mwolson]

How I'd probably recommend to thread the needle between standards compliance, new terminal functionality, and user expectations with the caveat of no terminal dev experience:

Linux:

• Default emoji with no selector: always default to color. Probably would ignore emoji_representation entirely in the unicode.org table as advice targeted at browsers that might or might not ever be followed.
• Emoji with text selector: always render as text: this is a feature and support for it is a way Ghostty is deliberately different than the rest; address config reload issue.
• Emoji with color selector: always render as color
• Emoji with invalid selector: don't render, it's a visual cue to the user that something is not right, and Ghostty catches it unlike other tools due to enhanced support for emoji selectors

macOS:

• Default emoji with no selector: Same as Linux.
• Emoji with text selector: Always render as color in short term - caveat in the docs that Apple doesn't support text selectors for emojis properly in their fonts. Long term, maybe embed an emoji font but sounds very challenging unless someone already built an Apple Emoji facsimile font.
• Emoji with color selector: Same as Linux.
• Emoji with invalid selector: Same as Linux.

Other possibility:

• Configuration option to let the user choose colorization of emoji that lack a selector, options something like: { always_color, always_text, follow_defaults }.

[mitchellh]

Thanks for the writeup. Just wanted to let you know I'm still paying attention but some other higher priority things popped up. I think we can extract one or two actionable issues from this so I plan on coming back to this shortly. Thank you!

[chubin]

Thank you for letting me know about this problem.

I've created a follow-up issue on wttr.in:

chubin/wttr.in#1053

We will try to find a good approach from the wttr.in side regarding how we should handle this problem.

Another one, which is quite similar but not exactly the same:

that the same symbols have different widths in different terminals, for example, here is how the same output is displayed in Alacritty and Ghostty.

Alacritty:

Ghostty:

In your opinion:

1. Can we define the "correct" width for each symbol (that we expect from each terminal), or would it be too strict?
2. How should we approach terminals that use "incorrect" widths? Maybe we could create some 'classes' of them and make it possible to specify the "class" of the terminal as a part of the query?

The second question is rather wttr.in specific, but your opinion would be very helpful.

[mwolson]

When I set this ghostty option to legacy and reopen it, the above text renders well just like in Alacritty: https://ghostty.org/docs/config/reference#grapheme-width-method . Ideally the default behavior of wttr.in would be to have output that renders correctly when that ghostty option is set to unicode (the default) and let users provide an option to flip the output back to something compatible with legacy, perhaps that would solve a decent number of cases with minimal complexity.

[nlopes]

Apologies for chiming in pretty much a year later.

Setting grapheme-width-method = legacy fixes an emacs emoji rendering bug (which I can only assume is directly related with this).

If it helps (but feel free to ignore), adding an asciinema cast file + emacs .el file showing how this looks if that setting is set to unicode:
emacs-ghostty-emoji-troubleshooting.tgz

I'm not the author of the .el file I shared - that comes from this email thread in the emacs mailing list (in relation to a discussion about emoji+emacs issues in the Kitty terminal).

I'm adding all of the above here in case it is useful to have someone willing to test/help etc. Unfortunately I don't know enough of the Emacs codebase to be useful there (and the Emacs devs don't seem to be keen on implementing the Kitty algorithm) so grapheme-width-method = legacy might very well be something folks using emacs are stuck with.

Let me know if I can help in any way!