【求助】在 wsl2 中启动 Emacs，组合的 Emoji 会导致 buffer 渲染错误

Emacs-general
1

当我在 wsl 下的 emacs 输入 emoji： :airplane:，我的 buffer 就开始乱跳了。

执行 describe-char 可以看到，这个 emoji 是由：

  • :airplane: (#x2708) AIRPLANE
  • (#xfe0f) VARIATION SELECTOR-16

组合而成的

             position: 1 of 2 (0%), column: 0
            character: ✈ (displayed as ✈) (codepoint 9992, #o23410, #x2708)
              charset: unicode (Unicode (ISO10646))
code point in charset: 0x2708
               script: symbol
               syntax: w 	which means: word
             category: .:Base
             to input: type "C-x 8 RET 2708" or "C-x 8 RET AIRPLANE"
          buffer code: #xE2 #x9C #x88
            file code: #xE2 #x9C #x88 (encoded by coding system utf-8)
              display: composed to form "✈️" (see below)

Composed with the following character(s) "️" by these characters:
 ✈ (#x2708) AIRPLANE
 ️ (#xfe0f) VARIATION SELECTOR-16

Character code properties: customize what to show
  name: AIRPLANE
  general-category: So (Symbol, Other)
  decomposition: (9992) ('✈')

There are text properties here:
  fontified            nil

对于这样的 emoji，当我输入到 wsl 中会导致 emacs buffer 渲染崩坏：

执行步骤：

  1. 粘贴 emoji
  2. 执行 C-g

表现： 原来我可以准确地在行之间移动，但是一旦存在这样的 emoji，我就无法准确的移动到我想去的行，它会导致行间显示的内容错乱，原来显示在第二行的内容会视觉上变成第一行，内容多时候，整个buffer 显示的内容都是错乱的。

demo

我运行的环境：

  • wsl2
  • ubuntu
  • window terminal
  • emacs 30.1（原来 29 版本也有问题）

我尝试了：

  1. 使用 emojify-mode，将 emoji 渲染模式改为 image，但当我粘贴 :airplane: 到 buffer 依然会出现问题

  2. 尝试在 window terminal 中配置 ubuntu 的字体，配置成 window 上的 emoji 字体 Segoe UI Emoji 也是不行

  3. 通过 window 自带的输入法输入的 emoji 似乎没问题，可能输入的不是拼接起来的 emoji

希望得到一些排查思路，或者有没有碰到类似问题，是如何解决的

我也能接受不显示 emoji，将它显示为文本，不影响在 buffer 中的操作就好

2

最近有在windows机器上看代码的需求，在windows terminal里面运行emacs时发现diminish的emoji都直接显示成了转义序列。

因为escape是terminal实现的功能，我怀疑这是windows terminal的问题，不知道是否与unicode编解码有关。

3

如果是 terminal 问题的话，我可以尝试换个 terminal 试试效果，晚点试试 https://tabby.sh/

尝试过了，也是不行

4

这个主要应该是 conpty 的问题。

windows 的 conpty 的实现就是很不稳健。之前 nerd font 升级到 v3 也出现过类似的渲染特殊字符的问题。

我在 2023 年 7月的时候提过类似的情况

其次如果需要使用交互式的终端 app，比如 vim neovim emacs-nw tmux 等，windows 的 伪终端实现 （conpty） 并不健壮，会有各种各样的 bug，前段时间 nerd font 升级到 v3 的时候直接导致 tty 各种字符显示不正常，直到后来才修复了这个 bug。其次我还遇到过 conpty 在使用 zsh fzf 的时候 有难以复现的 bug 导致整个 shell 进程直接闪退。而且这个 conpty 是只要在 windows 上使用终端 不管是 native win 还是 wsl 或者 ssh 都无法避开的，健壮性非常不足。

具体的可以参考如下的 github issue。

可以看到有成吨的 conpty 的问题。

需要注意的是所有的 windows 下的终端软件都需要调用 conpty 这个库。因此一个尝试解决方案的思路就是安装 windows terminal preview，这个打包了上游正在开发的 nightly conpty 库，如果还是有问题那就基本没救了，只能等 MS 修 bug 了。

这种情况建议改用 WSLg吧、也就是 GUI emacs。

2 个赞
5

目前在用的就是 window terminal preview，问题还是存在。

换成 WSLg 应该是可行的，只是目前习惯了在 terminal 里使用，如果能解决这个问题就好el。

6

WSL 终归不是真正的 linux。conpty 是 WSL 终端用户的最大痛点。很多人只用 vscode remote 来连接 wsl，终端只跑 bash 脚本，简单跑下 cargo npm 之类的一行命令的，根本体会不到我说的场景。就说什么什么 WSL 是最好的 linux 发行版，很好笑。

2 个赞
7

有没有试过换字体？我这里用wsl2/Windows termial中启动emacs TUI没有出现楼主的问题。配置如下：

image
image1310×628 15.1 KB

用alacritty，wzterm之类的就会出现跳动的问题，甚至没有emoji也会出现。

8

可以试试cygwin的mintty，用的是winpty

9

尝试了，不行 :melting_face: thanks

10

尝试了，也不行 = =

我把那个 emoji 直接复制到 window terminal 也是显示有问题的：

image

暂时先这样了，emoji 我其实用的不多，只是现在有的 LLM 会返回，导致用起来有点膈应。

11

Windows上处理emoji就是会有点小bug，我之前写的正则 .+[🌱🌞🍂❄️] 就会匹配到非这四个emoji结尾的内容。

12

Mintty 已经从 winpty 切换到了 conpty。那么所有 windows 终端会遇到的 conpty 的各种小毛病都无法避免

13

:open_mouth:我没注意到winpty是个更古老的项目，github上已经停止更新8年了，不知道还有没有人在维护，看起来conpty现在是唯一选择。

这个问题应该可以在前端解决，因为接收粘贴文本的是窗口，所以，也许还有我们不知道的终端模拟器☺虽然conpty的毛病并不能规避。

14

原回答删了

重新试了下，确实换 ssh 客户端也没用。。

15

按照我的理解，欢迎指正。

conpty / unix pty 之于终端软件，就相当于 X / wayland 之于图形软件。所以只要是运行在宿主机上的终端软件，不管连接到的 shell 在什么地方运行，都是绕开不了的。

16

vte更接近一个wayland compositor吧，接收输入和绘制内容的都是终端模拟器，实际兼具了server和renderer的作用。

17

最初的回答怀疑 ssh 是由于俺没少因 win 原生 ssh 显示异常 or 输入诡异转义符，换成 git bash 下的 ssh 或者直接换成 tssh 能解决我大部分问题（但解决不了 op 的。。我这也错位）

关于 conpty, 俺以为 mintty 会例外，毕竟印象里 mintty 能创建 tmux 窗口就是因为绕开了 conpty, 但是看到你上边说的 mintty 切换至 conpty, 俺也有点懵了。。。