strange terminal output in wsl on wezterm with tmux

[sedlund]

What system are you running Yazi on?

Windows WSL

What terminal are you running Yazi in?

wezterm 20240203-110809-5046fc22

yazi --debug output

strange terminal output below at the beginning and the end of the debug output.

---

yazi --debug
^[P>|WezTerm 20240203-110809-5046fc22^[\
Yazi
    Version: 0.3.1 (Nixpkgs 2024-08-15)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.3.1 (Nixpkgs 2024-08-15)

Emulator
    Emulator.via_env: ("xterm-256color", "WezTerm")
    Emulator.via_csi: Ok(Unknown([]))
    Emulator.detect : WezTerm

Adapter
    Adapter.matches: Iterm2

Desktop
    XDG_SESSION_TYPE: None
    WAYLAND_DISPLAY : None
    DISPLAY         : None

SSH
    shared.in_ssh_connection: false

WSL
    /proc/sys/fs/binfmt_misc/WSLInterop: true

Variables
    SHELL              : Some("/run/current-system/sw/bin/zsh")
    EDITOR             : Some("lvim")
    VISUAL             : None
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None

Text Opener
    default: Some(Opener { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })
    block  : Some(Opener { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })

Multiplexers
    TMUX               : false
    tmux version       : 3.4
    ZELLIJ_SESSION_NAME: None
    Zellij version     : No such file or directory (os error 2)

Dependencies
    file             : 5.45
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: 2.2.2
    magick           : 7.1.1-36
    fzf              : 0.54.3
    fd               : 10.1.0
    rg               : 14.1.0
    chafa            : 1.14.2
    zoxide           : 0.9.4
    7z               : No such file or directory (os error 2)
    7zz              : 24.08
    jq               : 1.7.1

--------------------------------------------------
When reporting a bug, please also upload the `yazi.log` log file - only upload the most recent content by time.
You can find it in the "/home/sedlund/.local/state/yazi" directory.

wsl in ~/test/deep
at 20:59:55  ❮ weztemm 20240203-110809-5046fc22^M

Did you try the latest nightly build to see if the problem got fixed?

Yes, and I updated the debug information above (yazi --debug) to the nightly that I tried

Describe the bug

Under WSL (NixOS) with WezTerm and Tmux i am getting strange output from yazi when running --version --help --debug. When starting yazi directly it opens FZF before starting yazi, then after I cancel FZF, yazi opens then asks me to enter a filter.

Here is asciicinema:

The above configuration that is broken is:

WSL (NixOS unstable), connected with WezTerm, executing under Tmux

These configurations of the same machine work fine:

• WSL, WezTerm, Zellij
• WSL, WezTerm, Tmux with yazi 0.2.5 from NixOS 24.05 opens fine
• WSL, Windows Terminal, Tmux
• WSL, Windows Terminal, Zellij

Here is WSL Ubuntu, Wezterm, Tmux and Yazi 0.3.1:

It opens the rename dialog upon open:

Minimal reproducer

WSL Wezterm and Tmux

Anything else?

No response

[sxyazi]

Please comment out these 3 lines one by one and all together to see what happens:

https://github.com/sxyazi/yazi/blob/cd7209c040a706bd826b20f47d4accdcf0c5a762/yazi-fm/src/term.rs#L31-L33

[sedlund]

commenting line 33 fixes fzf from starting and the the filter dialog from opening. although after starting, the screen blanks, and it takes about 10 seconds for the initial screen to load.

Also immediately after execution the window looses mouse focus. so once the screen paints I have to press a key to regain focus then yazi accepts input.

seems CSI u is not supported in tmux quite yet: https://github.com/tmux/tmux/issues/4072#issuecomment-2301158506

[sxyazi]

Please try https://github.com/sxyazi/yazi/pull/1564

[sedlund]

behaviour is same as the original.

i am patching against 0.3.1 if that's ok

          yazi = pkgs.yazi-unwrapped.overrideAttrs (
            _: super: {
              pname = super.pname + "-patched";
              patches = super.patches or [ ] ++ [
                (pkgs.fetchpatch {
                  url = "https://github.com/sxyazi/yazi/pull/1564.patch";
                  hash = "sha256-bzX4ImTyiqZ0PRXlqycWMb/RBMIm7+58Vh8OAeKg6i8=";
                })
              ];
            }
          );

[sxyazi]

Well, if this doesn't work, then I really don't know what else to do. My best guess is that it could be either tmux or ConPTY causing interference with Yazi's behavior, or maybe both. But I can only try to fix the issue with tmux (which is already included in that PR). As for ConPTY's behavior, there's nothing I can do about it. We'll just have to hope it gets resolved gradually with future operating system updates.

I'll merge that PR first, as in my testing it does have some effect. Then I'll keep this issue open for a while to see if anyone else encounters it and can help debug it at the code level.

[sedlund]

i am using this and its working for me

diff --git a/yazi-adapter/src/emulator.rs b/yazi-adapter/src/emulator.rs
index 1d6cf10..7e6d7ab 100644
--- a/yazi-adapter/src/emulator.rs
+++ b/yazi-adapter/src/emulator.rs
@@ -209,7 +209,7 @@ impl Emulator {
            Ok(())
        };

-       match timeout(Duration::from_secs(10), read).await {
+       match timeout(Duration::from_secs(1), read).await {
            Err(e) => error!("read_until_da1 timed out: {buf:?}, error: {e:?}"),
            Ok(Err(e)) => error!("read_until_da1 failed: {buf:?}, error: {e:?}"),
            Ok(Ok(())) => {}
diff --git a/yazi-fm/src/term.rs b/yazi-fm/src/term.rs
index f68cd61..37a4ecd 100644
--- a/yazi-fm/src/term.rs
+++ b/yazi-fm/src/term.rs
@@ -30,7 +30,7 @@ impl Term {
            BufWriter::new(stderr()),
            Print("\x1b[?12$p"),      // Request cursor blink status (DECSET)
            Print("\x1bP$q q\x1b\\"), // Request cursor shape (DECRQM)
-           Print("\x1b[?u\x1b[c"),   // Request keyboard enhancement flags (CSI u)
+           // Print("\x1b[?u\x1b[c"),   // Request keyboard enhancement flags (CSI u)
            EnterAlternateScreen,
            EnableBracketedPaste,
            mouse::SetMouse(true),

[sxyazi]

What happens when you run each of these 3 lines separately?

echo -e '\x1b[?u\x1b[c'; cat
echo -e '\x1b[?u'; cat
echo -e '\x1b[c'; cat

[sedlund]

i have to press C-c after each to cancel cat:

[sxyazi]

Is it inside tmux of these outputs? BTW, are you using the default configs for tmux, WezTerm, and Yazi - does the issue occur with the default settings? Also, have you tried connecting to WSL through SSH? That's our recommended method since it can bypass interference from ConPTY https://yazi-rs.github.io/docs/image-preview#wsl

[sedlund]

The one above is from the same WSL (NixOS) / WezTerm / Tmux. I am not using default configs, but i can't think of anything in it that would change that behaviour.

In a separate WSL with Ubuntu-22.04, tmux 3.2a, yazi 0.3.1 -- everything default:

./yazi --version
Yazi 0.3.1 (4112bf4 2024-08-15)
^[P>|WezTerm 20240203-110809-5046fc22^[\sedlund@g15:~$ :>|WezTerm 20240203-110809-5046fc22^[\

and after starting yazi it will open the filter dialog

Same Ubuntu all defaults:

---

I tried connecting through WezTerm SSHMUX and everything there is fine with stock 0.3.1

[sxyazi]

If SSH is working fine, then it's very likely that the issue is caused by ConPTY, in this case, there's not much that Yazi can do.

Keep in mind that it's still possible that the combination of tmux and ConPTY is causing the problem as they tend to reorder CSI sequences and interfere with the communication between Yazi and the terminal in various ways. However, in this case, using SSH to bypass ConPTY seems to make tmux function normally.

I'll keep this issue open for a while to see if anyone familiar with Windows can help debug and find a workaround. Although in the end, it might not be solvable because it's beyond Yazi's scope.

[mau-mauricelim]

I have a similar issue on WSL Alpine and Ubuntu on WezTerm as well

WSL Distro: Ubuntu 24.04 LTS and Alpine Linux v3.20 Yazi version: Yazi 0.3.0 (VERGEN_IDEMPOTENT_OUTPUT 2024-08-01) Tmux version: tmux 3.4 WezTerm version: wezterm 20240203-110809-5046fc22

The issue is not present on Windows Terminal and Alacritty.

[sxyazi]

Thanks for the info! If this issue only happens in WezTerm and not in Windows Terminal or Alacritty, then I think it's very likely related to WezTerm, but it could still be ConPTY or tmux interfering in some way with the communication between Yazi and the terminal. Maybe filing an issue with WezTerm would help, since it seems like the issue is only showing up there.

I'm going to close this issue now, as it’s really a bit outside the scope of Yazi. Yazi just receives key events from the terminal and executes them as is. In this case, WezTerm sent the key event to open the search box, so some debugging might be needed at the terminal level.

[sxyazi]

Oh just a quick check - @mau-mauricelim I noticed that your Yazi version is 0.3.0, but the PR (https://github.com/sxyazi/yazi/pull/1564) that tried to fix this issue was only included in version 0.3.2. Have you tried the latest version of Yazi to see if the issue still?

[mau-mauricelim]

@sxyazi thanks for the update! I went and tested Yazi 0.3.3 and the issue still persists.

[j4james]

@sxyazi I can't comment on the tmux side of things, but one of places where ConPTY is likely to cause problems is with your XTVERSION query here:

https://github.com/sxyazi/yazi/blob/61c0db8630bf48ff3fd3919f736704837f50f7f5/yazi-adapter/src/emulator.rs#L129

This is because ConPTY handles most of the VT sequences itself, but when it encounters something it doesn't recognise (like XTVERSION), it typically just passes that through to the connected terminal to handle.

So in the code above, the XTVERSION gets passed through, but the DA1 query is handled by ConPTY. And that often results in the DA1 response being sent before the client terminal has a chance to send its XTVERSION response.

And since you're blocking on the DA1 response, you think you've received everything, when in fact the version string is still on its way. The end result is the version gets echoed as keyboard input (the ^[P>|WezTerm 20240203-110809-5046fc22^[\ that was seen in the original report).

The good news is that this should be fixed by the new ConPTY implementation that Windows Terminal is currently previewing. With the new implementation, essentially all VT sequences are passed through to the client terminal, so all the responses should come back in the right order.

That new version of ConPTY is still being tested, and there are a few issues that still need to be resolved, but once it's stable I suspect WezTerm will be keen to start using it, and then problems like this should be a thing of the past.

[sxyazi]

Oh my lord, you saved my day! Thank you for the detailed explanation, everything makes sense now!

As a TUI tool developer, I'm really excited to hear this amazing news, this means I won't have to deal with all the quirks of ConPTY anymore. I really hope it stabilizes soon, and I'm also super grateful for all the work you've done on Windows Terminal. Much respect!