Issues with emoji support

[sockdrawermoney]

I will admit that I only have a millimeter deep understanding of this, but based on what I can gather, Blink does not seem(?) to have complete emoji support, and is certainly missing color emoji.

For example, when pasting into Blink: 👨🏿‍🏫

Blink renders it as:

This is particularly problematic for editing in vim any files that contain emoji with skin color. These emoji get this <200d> blob and then for the rest of the line, the cursor is not on the character where it appears. (In the example below, the cursor is actually on the space prior to the word "Artists")

I do get the same <200d> and the cursor bug shows up when opening unicode standard's test-emoji.txt file.

I fully understand this actually might be a bug well beyond Blink itself, but at a minimum, Blink itself does not seem to properly handle color emoji or some of the newer emoji like "professor", as illustrated by the first example.

When I am able to, I will test a different combination of servers and clients to try to narrow down the consistency in these issues.

[philips]

Tested on iPadOS 13.5 and emoji rendering isn’t working well. I tested out different fonts including Menlo, Source Code Pro, etc with no change in behavior

Panic’s Prompt 2 is able to render the emojis but has issues with line spacing and duplication.

[rrgeorge]

I have noticed that over mosh, blink does not support emojis over unicode f09f a691 I tried the command echo -e "\xf0\x9f\xa6\xa3" in these environments: These work: blink ssh -> linux blink ssh -> macOS linux mosh -> localhost blink ssh -> linux and mosh -> localhost These dont work: blink mosh -> linux blink mosh -> macOS macOS mosh -> localhost blink ssh -> linux, mosh -> macOS blink ssh -> macOS, mosh -> linux

I went back and lowered the finally byte till I found the last displayed emoji is: f09f a691 (🦑)

[xero]

i can also confirm this.

this happens over ssh or mosh, with or without tmux, but it's more visually drastic in a multiplexer, so i'm sharing screenshots like that.

certain emojis render fine:

but i use the hack nerd font for blink, and it contains certain unicode emojis. they render, then blink overwrites them a second later. when that happens the term col offset get's skewed:

it seems worse for combined emojis (e.g. 🏴‍☠️):

and if you put a bunch of stacked emojis in a file and open them in neovim, things get wacky very quickly 🙃

my guess is that blink isn't correctly calculating offsets for when a unicode char is already rendered for an emoji it plans to replace. and it multiplies for each combing character.

i'd personally like an "emoji off" setting as a stop gap until a proper fix. but that's just an opinion.

testing

• newest blink test flight build: 17.30.911
• newest mosh build: 1.4.0
• os: debian 11
• tmux: next 3.5 (happens w/o it)
• emoji-fzf (with or w/o fzf bin)

test script using fzf:

#!/bin/bash
# pip install emoji-fzf
e=$(emoji-fzf preview | fzf -m --preview "emoji-fzf get --name {1}" | cut -d " " -f 1 | emoji-fzf get)
[[ -n "$TMUX" ]] && c="tmux loadb - " || c="xsel -i"
[[ -n "$e" ]] && printf %s "$e" | $c

but you can just get a full list of text only by running: emoji-fzf preview --append

final note:

nerd font icons and other utf8 characters render perfectly fine. closing your tmux buffer, or running clear; reset fixes all emoji offset issues (until the next render).