Why does Visual Studio Code display some emojis wrong?

Question

I am trying to print different emojis in python using visual studio code. However, when I print some emojis (just using print()) some (not all) emojis get displayed using the wrong width, more specifically if a character is printed next to it it will over lap the emoji. This will make more sense visually:

For some emojis its perfectly fine: print("😃😄😂") |

However for others this happens: print("😂🪵") |

That's a log emoji (though it happens to many others as well), the face emoji overlaps the log emoji because vs-code doesn't give it the correct width (I'm pretty sure all emojis are twice as wide as a normal alphabetic character). This only happens in the Terminal not in the editor. I have absolutely no idea why this happens for only some emojis I have tried changing the font but it has absolutely no effect.

Not sure if this is helpful but I was previously using a different code editor where all emojis where displayed incorrectly i.e. Not being recognised as larger than a normal char however in that code editor all emojis where displayed that way so I just added a space after every emoji to stop them overlapping however in vs code only some are incorrect. (Adding spaces to just some emojis is very inconvenient and I don't see why this should be an issue in the first place)

If I try this in command prompt by typing python and then print("😂🪵") it works fine, so I believe it is specifically an issue with VS Code's integrated terminal.

EDIT: I am using the latest version of vs code (1.78.0) and the latest version of python (3.11.3) and yes I am using windows. I would like to clarify what I mean by the vs code terminal, here is an image: ibb.co/J7tMCZX this issue is specific to running code inside the visual studio code application, If I open a command prompt window and navigate to the file path and type "python test.py" to run the file I get no issues.

Answer 1

I can't reproduce this issue in VS Code's integrated terminal with version 1.78.0 of VS Code with Python 3.10.6 on Ubuntu 22.04.1. It doesn't happen if I run the print in an interactive python prompt, or if I run a file containing the print.

But what I can do is shed light on how glyph widths are supposed to work in VS Code's integrated terminal:

VS Code uses xtermjs to implement its integrated terminal. Mini rabbit hole: google "github xterm.js issues some emoji take up one character width instead of two" -> https://github.com/xtermjs/xterm.js/issues/1059 -> https://github.com/xtermjs/xterm.js/issues/1709 -> https://github.com/xtermjs/xterm.js/pull/2568/files -> https://github.com/jerch/xterm.js/blob/master/src/common/input/UnicodeV6.ts#L88, which is the file in xterm.js that determines what width to give to glyphs. It would be a bit ridiculous for me to paste the whole file here, but here's a little window into what's going on in there (see the full file for all the context):

public wcwidth(num: number): CharWidth {
  if (num < 32) return 0;
  if (num < 127) return 1;
  if (num < 65536) return table[num] as CharWidth;
  if (bisearch(num, HIGH_COMBINING)) return 0;
  if ((num >= 0x20000 && num <= 0x2fffd) || (num >= 0x30000 && num <= 0x3fffd)) return 2;
  return 1;
}

The wood emoji is 0x1FAB5 (decimal: 129717), which as far as I can tell from visual inspection, doesn't match any of the if blocks, and hits the final return 1; in wcwidth, which matches the behaviour I see in my integrated terminal.

Also note that a lot of terminal emulators have varying behaviours with emoji width that some find confusing or frustrating. see also https://github.com/alacritty/alacritty/issues/6144, and https://github.com/microsoft/terminal/issues/8970. I myself have encountered various differences between windows terminal, macOS' default terminal app, GNOME terminal, etc. and I can empathize that these issues are a pain when working on projects that benefit from consistency in these areas.

---

Note: At the time of the posting of the above question, this wasn't a thing, but be aware that since VS Code 1.88, rescaling of overlapping glyphs in the terminal is a thing. See related release notes.