kovidgoyal / kitty

Cross-platform, fast, feature-rich, GPU based terminal
https://sw.kovidgoyal.net/kitty/
GNU General Public License v3.0
24.56k stars 982 forks source link

Broken Rendering of Characters Composed of Multiple Code Points in kitty + tmux #6355

Closed mrmeowski closed 1 year ago

mrmeowski commented 1 year ago

Description

Characters composed of multiple Unicode code points (e.g., πŸ‘πŸ» which is composed of U+1F44D and U+1F3FB) do not render properly when running neovim inside tmux inside kitty.

Steps to Reproduce

  1. Run kitty without any configuration from a different terminal: kitty --config NONE.
  2. Run tmux without any configuration inside kitty: tmux -f /dev/null new.
  3. Run printf "Test\n'πŸ‘' Test\n'πŸ‘πŸ»' Test\n" > test.txt.
  4. Run neovim without any configuration in tmux: nvim -u NONE -c 'set colorcolumn=80' test.txt
  5. Observe the broken colorcolumn rendering in neovim.

Screenshots

  1. Running neovim in tmux inside of kitty (broken colorcolumn rendering in neovim):

image

  1. Running neovim directly in kitty without tmux (i.e., without step 2 above):

image

  1. cat test.txt inside of tmux:

image

Environment Details

kitty 0.28.1 created by Kovid Goyal
Linux dev-vm 6.3.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 05 Jun 2023 15:12:57 +0000 x86_64
Arch Linux 6.3.6-arch1-1 (/dev/tty)

Running under: Wayland
Frozen: False
Paths:
  kitty: /usr/bin/kitty
  base dir: /usr/lib/kitty
  extensions dir: /usr/lib/kitty/kitty
  system shell: /usr/bin/zsh

Config options different from defaults:

Important environment variables seen by the kitty process:
    PATH                                /usr/local/bin:/usr/bin:/usr/local/sbin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
    LANG                                en_US.UTF-8
    EDITOR                              nvim
    SHELL                               /usr/bin/zsh
    DISPLAY                             :0
    WAYLAND_DISPLAY                     wayland-0
    USER                                dev
    XDG_CURRENT_DESKTOP                 GNOME
    XDG_MENU_PREFIX                     gnome-
    XDG_DATA_DIRS                       /home/dev/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/
    XDG_SESSION_DESKTOP                 gnome
    XDG_RUNTIME_DIR                     /run/user/1000
    XDG_SESSION_TYPE                    wayland
    XDG_SESSION_CLASS                   user

Additional Context

This seems similar to https://github.com/wez/wezterm/issues/3704.

mrmeowski commented 1 year ago

I think we can actually take neovim out of the equation; the issue can be reproduced just with kitty + tmux. Here are the updated steps to reproduce:

  1. Run kitty without any configuration from a different terminal: kitty --config NONE.
  2. Run printf "Test\t\t|\n'πŸ‘' Test\t|\n'πŸ‘πŸ»' Test\t|\n" > test.txt.
  3. Run cat test.txt.
  4. Observe that the | characters are aligned properly.
  5. Run tmux without any configuration inside kitty: tmux -f /dev/null new.
  6. Run cat test.txt.
  7. Observe that the | characters are misaligned.

This is how test.txt renders in:

kitty:

image

kitty + tmux:

image

Gnome Terminal:

image

Gnome Terminal + tmux:

image

@kovidgoyal, I know you discourage using terminal multiplexers, but maybe you have a clue about how to avoid this problem while still using tmux in kitty? Is there a configuration option to prevent kitty from combining code points for emojis and display the code points individually as Gnome Terminal does.

kovidgoyal commented 1 year ago

No there is no such configuration. kitty will display unicode codepoints as per the unicode standard. I am not going to add configuration options to work around bugs in tmux.

sesse commented 1 year ago

I am seeing this (extra space after complex emoji) without a terminal multiplexer:

printf 'Happy Pride \360\237\217\263\357\270\217\342\200\215\360\237\214\210!\n'

image

Reproduced using the static kitty 0.28.1 binary for Linux amd64.

Edit: Seemingly this is #6323 / #3810?

kovidgoyal commented 1 year ago

yes it is the same zwj issue