Tmux pane content gets garbled after refreshing tmux client #5654

Closed
opened 2026-01-31 00:18:22 +00:00 by claunia · 35 comments
Owner

Originally created by @abhirup-dev on GitHub (Dec 20, 2019).

Environment

Windows build number: 19041
Windows Terminal version: 0.7.3
tmux: 2.6

Steps to reproduce

  1. Run command such as htop, top inside a tmux pane
  2. Press Prefix + r (:refresh-client) to refresh the tmux client
    (I actually faced this problem during the course of my but was later able to reproduce it using steps 1 and 2.

Expected behavior

Nothing should happen. The command mentioned in step 1 should continue to run without any changes. In fact, that is what happens in minTTY terminal that ships by default with WSL.

Actual behavior

The output from htop gets garbled. Only the changing parts of the text, like fluctuating RAM usage, reordering of processes gets reflected. See the given screenshots in this Reddit post.

Originally created by @abhirup-dev on GitHub (Dec 20, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: 19041 Windows Terminal version: 0.7.3 tmux: 2.6 ``` # Steps to reproduce 1. Run command such as `htop`, `top` inside a tmux pane 2. Press Prefix + r (`:refresh-client`) to refresh the tmux client (I actually faced this problem during the course of my but was later able to reproduce it using steps 1 and 2. # Expected behavior <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> Nothing should happen. The command mentioned in step 1 should continue to run without any changes. In fact, that is what happens in minTTY terminal that ships by default with WSL. # Actual behavior <!-- What's actually happening? --> The output from `htop` gets garbled. Only the changing parts of the text, like fluctuating RAM usage, reordering of processes gets reflected. See the given screenshots in this [Reddit post](https://www.reddit.com/r/tmux/comments/ed8f4b/tmux_garbled_pane_after_continued_use_windows/).
Author
Owner

@zadjii-msft commented on GitHub (Dec 20, 2019):

This is curious - I can't seem to repro this:
image

No matter how many times I tried, refresh-client didn't seem to corrupt the display at all.

Perhaps there's something more about your machine's config that's causing this. What's TERM set to? Which linux distro is this?

@zadjii-msft commented on GitHub (Dec 20, 2019): This is curious - I can't seem to repro this: ![image](https://user-images.githubusercontent.com/18356694/71258251-549e0800-22fb-11ea-92f6-cba914943747.png) No matter how many times I tried, `refresh-client` didn't seem to corrupt the display at all. Perhaps there's something more about your machine's config that's causing this. What's `TERM` set to? Which linux distro is this?
Author
Owner

@abhirup-dev commented on GitHub (Dec 20, 2019):

Within tmux, $TERM is set to "screen". Outside tmux, it is set to "xterm-256color". I'm using Ubuntu 1804.

No matter how many times I tried, refresh-client didn't seem to corrupt the display at all.

I'm able to reproduce this issue every time.

@abhirup-dev commented on GitHub (Dec 20, 2019): Within `tmux`, `$TERM` is set to "screen". Outside tmux, it is set to "xterm-256color". I'm using Ubuntu 1804. > No matter how many times I tried, refresh-client didn't seem to corrupt the display at all. I'm able to reproduce this issue every time.
Author
Owner

@zadjii-msft commented on GitHub (Dec 20, 2019):

@maverickdas There must be something specific to your setup then that's causing this, because I still can't get this to repro.

  1. What's the output of infocmp from within tmux?
  2. What font are you using?
  3. Which distro are you using?
  4. Could you share your .tmux.conf?
@zadjii-msft commented on GitHub (Dec 20, 2019): @maverickdas There must be something specific to your setup then that's causing this, because I still can't get this to repro. 1. What's the output of `infocmp` from within `tmux`? 2. What font are you using? 3. Which distro are you using? 3. Could you share your `.tmux.conf`?
Author
Owner

@abhirup-dev commented on GitHub (Dec 20, 2019):

What's the output of infocmp from within tmux?

#       Reconstructed via infocmp from file: /lib/terminfo/s/screen
screen|VT 100/ANSI X3.64 virtual terminal,
        am, km, mir, msgr, xenl,
        colors#8, cols#80, it#8, lines#24, ncv@, pairs#64,
        acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
        clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=\r,
        csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
        cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
        cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM,
        cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
        dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K,
        enacs=\E(B\E)0, flash=\Eg, home=\E[H, hpa=\E[%i%p1%dG,
        ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
        ind=\n, indn=\E[%p1%dS, is2=\E)0, kbs=^?, kcbt=\E[Z,
        kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
        kdch1=\E[3~, kend=\E[4~, kf1=\EOP, kf10=\E[21~,
        kf11=\E[23~, kf12=\E[24~, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
        kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
        khome=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
        nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O,
        rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[23m,
        rmul=\E[24m, rs2=\Ec\E[?1000l\E[?25h, sc=\E7,
        setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
        sgr=\E[0%?%p6%t;1%;%?%p1%t;3%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;m%?%p9%t\016%e\017%;,
        sgr0=\E[m\017, smacs=^N, smcup=\E[?1049h, smir=\E[4h,
        smkx=\E[?1h\E=, smso=\E[3m, smul=\E[4m, tbc=\E[3g,
        vpa=\E[%i%p1%dd,

What font are you using?

I'm using Source Code Pro font and acrylicOpacity is true.

Which distro are you using?

Ubuntu 1804. kernel - 4.19.84

Could you share your .tmux.conf?

Here

@abhirup-dev commented on GitHub (Dec 20, 2019): > What's the output of infocmp from within tmux? ``` # Reconstructed via infocmp from file: /lib/terminfo/s/screen screen|VT 100/ANSI X3.64 virtual terminal, am, km, mir, msgr, xenl, colors#8, cols#80, it#8, lines#24, ncv@, pairs#64, acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=\r, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM, cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E(B\E)0, flash=\Eg, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS, is2=\E)0, kbs=^?, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\E[4~, kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O, rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[23m, rmul=\E[24m, rs2=\Ec\E[?1000l\E[?25h, sc=\E7, setab=\E[4%p1%dm, setaf=\E[3%p1%dm, sgr=\E[0%?%p6%t;1%;%?%p1%t;3%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;m%?%p9%t\016%e\017%;, sgr0=\E[m\017, smacs=^N, smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[3m, smul=\E[4m, tbc=\E[3g, vpa=\E[%i%p1%dd, ``` > What font are you using? I'm using Source Code Pro font and `acrylicOpacity` is true. > Which distro are you using? Ubuntu 1804. kernel - 4.19.84 > Could you share your .tmux.conf? [Here](https://gist.github.com/maverickdas/262745d9d1816bca044f3a6721ef73a3#file-tmux-conf)
Author
Owner

@DHowett-MSFT commented on GitHub (Jan 6, 2020):

Would you mind also sharing the output of infocmp outside of tmux? Thanks!

@DHowett-MSFT commented on GitHub (Jan 6, 2020): Would you mind also sharing the output of `infocmp` _outside_ of tmux? Thanks!
Author
Owner

@abhirup-dev commented on GitHub (Jan 7, 2020):

Output of infocmp from outside tmux:

#       Reconstructed via infocmp from file: /lib/terminfo/x/xterm-256color
xterm-256color|xterm with 256 colors,
        am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
        colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff,
        acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
        clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
        csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
        cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
        cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
        cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
        dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
        el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
        hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
        il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
        initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
        invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
        kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
        kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^?,
        kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
        kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
        kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
        kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
        kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
        kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
        kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
        kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
        kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
        kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
        kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
        kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
        kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
        kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
        kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
        kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
        kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
        kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
        kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
        kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
        kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
        memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8,
        rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM,
        rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
        rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>,
        rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m,
        rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
        setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
        setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
        sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
        sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
        smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=,
        smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
        u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c,
        u9=\E[c, vpa=\E[%i%p1%dd,
@abhirup-dev commented on GitHub (Jan 7, 2020): Output of `infocmp` from outside tmux: ``` # Reconstructed via infocmp from file: /lib/terminfo/x/xterm-256color xterm-256color|xterm with 256 colors, am, bce, ccc, km, mc5i, mir, msgr, npc, xenl, colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff, acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A, cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS, initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\, invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^?, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~, kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~, kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~, kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~, kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~, kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~, kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El, memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8, rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>, rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m, rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m, setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m, sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m, sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd, ```
Author
Owner

@andreibosco commented on GitHub (Apr 8, 2020):

I'm also having this issue with tmux, but it doesn't happen with only htop. Example: If I split tmux vertically and move to the new panel the bottom area of the terminal starts getting garbled.

@andreibosco commented on GitHub (Apr 8, 2020): I'm also having this issue with tmux, but it doesn't happen with only htop. Example: If I split tmux vertically and move to the new panel the bottom area of the terminal starts getting garbled.
Author
Owner

@fergalmoran commented on GitHub (Apr 8, 2020):

Hi @andreibosco and others, this issue has been triaged by the terminal team and is being tracked in this issue.
https://github.com/microsoft/terminal/issues/3487

More info on the journey here.
https://github.com/microsoft/terminal/issues/176

@fergalmoran commented on GitHub (Apr 8, 2020): Hi @andreibosco and others, this issue has been triaged by the terminal team and is being tracked in this issue. https://github.com/microsoft/terminal/issues/3487 More info on the journey here. https://github.com/microsoft/terminal/issues/176
Author
Owner

@andrei-yanovich commented on GitHub (Apr 10, 2020):

Setting locale to en_US
with sudo update-locale LANG=en_US.UTF8
solved the problem for me.
Before there was C.UTF8

@andrei-yanovich commented on GitHub (Apr 10, 2020): Setting locale to en_US with `sudo update-locale LANG=en_US.UTF8` solved the problem for me. Before there was C.UTF8
Author
Owner

@andreibosco commented on GitHub (Apr 10, 2020):

@andrei-yanovich my locale is already set to en_US.UTF8, but thanks for the suggestion

@andreibosco commented on GitHub (Apr 10, 2020): @andrei-yanovich my locale is already set to en_US.UTF8, but thanks for the suggestion
Author
Owner

@edrpls commented on GitHub (Jul 10, 2020):

I'm having the same issue, on both the latest Preview (1.1.1671.0 @fergalmoran's linked release) and latest stable version (1.0.1401), I also tried tmux 3.1b and 2.6.

LANG is set to en_US.UTF8

TERM is set to xterm-256color on both tmux and Windows Terminal.

Font is Cascadia Code.

Sometimes it breaks as soon as the vertical pane is open and sometimes it takes a while, but it always happens when I'm using tmux.

I have also tried enabling/disabling experimental.rendering.forceFullRepaint, but the results are the same.

On this image, I have two vertical panes open, only the right one should have content, but it's leaking into the left side, which should only show the prompt.

tmux_garbled

infocmp output is exactly the same inside or outside tmux:

#	Reconstructed via infocmp from file: /lib/terminfo/x/xterm-256color
xterm-256color|xterm with 256 colors,
	am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
	colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff,
	acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
	bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
	clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
	csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
	cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
	cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
	cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
	dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
	el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
	hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
	il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
	initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
	invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
	kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
	kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^?,
	kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
	kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
	kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
	kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
	kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
	kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
	kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
	kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
	kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
	kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
	kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
	kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
	kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
	kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
	kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
	kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
	kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
	kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
	kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
	kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
	kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
	memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8,
	rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM,
	rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
	rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>,
	rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m,
	rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
	setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
	setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
	sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
	sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
	smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=,
	smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
	u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c,
	u9=\E[c, vpa=\E[%i%p1%dd,
@edrpls commented on GitHub (Jul 10, 2020): I'm having the same issue, on both the latest Preview (1.1.1671.0 @fergalmoran's linked release) and latest stable version (1.0.1401), I also tried tmux 3.1b and 2.6. `LANG` is set to `en_US.UTF8` `TERM` is set to `xterm-256color` on both tmux and Windows Terminal. Font is Cascadia Code. Sometimes it breaks as soon as the vertical pane is open and sometimes it takes a while, but it always happens when I'm using tmux. I have also tried enabling/disabling `experimental.rendering.forceFullRepaint`, but the results are the same. On this image, I have two vertical panes open, only the right one should have content, but it's leaking into the left side, which should only show the prompt. ![tmux_garbled](https://user-images.githubusercontent.com/1082158/87104008-47575500-c21c-11ea-830e-f36fc1090d20.png) infocmp output is exactly the same inside or outside tmux: ``` # Reconstructed via infocmp from file: /lib/terminfo/x/xterm-256color xterm-256color|xterm with 256 colors, am, bce, ccc, km, mc5i, mir, msgr, npc, xenl, colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff, acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A, cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS, initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\, invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^?, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~, kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~, kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~, kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~, kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~, kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~, kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El, memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8, rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>, rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m, rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m, setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m, sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m, sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd, ```
Author
Owner

@DHowett commented on GitHub (Jul 10, 2020):

Huh. Are any of the non-low-ASCII glyphs displayed on your screen double-width? You can tell by trying to select them (hold down Shift if tmux is claiming mouse input)

@DHowett commented on GitHub (Jul 10, 2020): Huh. Are any of the non-low-ASCII glyphs displayed on your screen double-width? You can tell by trying to select them (hold down <kbd>Shift</kbd> if tmux is claiming mouse input)
Author
Owner

@edrpls commented on GitHub (Jul 10, 2020):

@DHowett Thanks for your reply, I hope I understood this correctly, I've been selecting all the glyphs I can find and it seems they are all using just one space:

image
image
image

Did I do it right or did I completely misunderstood?

@edrpls commented on GitHub (Jul 10, 2020): @DHowett Thanks for your reply, I hope I understood this correctly, I've been selecting all the glyphs I can find and it seems they are all using just one space: ![image](https://user-images.githubusercontent.com/1082158/87104753-7bcc1080-c21e-11ea-8013-e9c09c12b11c.png) ![image](https://user-images.githubusercontent.com/1082158/87104756-7d95d400-c21e-11ea-8f0f-09831489f259.png) ![image](https://user-images.githubusercontent.com/1082158/87104758-7f5f9780-c21e-11ea-81aa-07cbfc7b2b1e.png) Did I do it right or did I completely misunderstood?
Author
Owner

@DHowett commented on GitHub (Jul 10, 2020):

That's exactly what I was after. Thank you. 😄

@DHowett commented on GitHub (Jul 10, 2020): That's exactly what I was after. Thank you. :smile:
Author
Owner

@edrpls commented on GitHub (Jul 10, 2020):

@DHowett btw, should I try that on the Preview or Stable version?

@edrpls commented on GitHub (Jul 10, 2020): @DHowett btw, should I try that on the Preview or Stable version?
Author
Owner

@DHowett commented on GitHub (Jul 10, 2020):

Fortunately, that one doesn't matter!

@DHowett commented on GitHub (Jul 10, 2020): Fortunately, that one doesn't matter!
Author
Owner

@edrpls commented on GitHub (Jul 10, 2020):

Not sure if this would help debug the issue, but I just noticed that floating windows in neovim inside tmux also suffer from a similar issue, where part of them will be rendered on the left side of the terminal.

image

When the floating window is closed, it leaves some artifacts behind at the edge of the screen:

image

This doesn't happen when running neovim outside tmux.

@edrpls commented on GitHub (Jul 10, 2020): Not sure if this would help debug the issue, but I just noticed that floating windows in neovim inside tmux also suffer from a similar issue, where part of them will be rendered on the left side of the terminal. ![image](https://user-images.githubusercontent.com/1082158/87184740-2b03f880-c2ae-11ea-8134-9f63dafd2ee3.png) When the floating window is closed, it leaves some artifacts behind at the edge of the screen: ![image](https://user-images.githubusercontent.com/1082158/87184955-88984500-c2ae-11ea-9b88-afcba88bc6f8.png) This doesn't happen when running neovim outside tmux.
Author
Owner

@fergalmoran commented on GitHub (Jul 10, 2020):

@edrpls - this is fixed for me in the latest preview 1.1.1812.0

@fergalmoran commented on GitHub (Jul 10, 2020): @edrpls - this is fixed for me in the latest preview 1.1.1812.0
Author
Owner

@edrpls commented on GitHub (Jul 10, 2020):

Thanks @fergalmoran, I'll try that version.

@edrpls commented on GitHub (Jul 10, 2020): Thanks @fergalmoran, I'll try that version.
Author
Owner

@edrpls commented on GitHub (Jul 16, 2020):

I have been testing out preview 1.1.1812.0, and while the issue is not as frequent, it still happens with vertical panes.

@edrpls commented on GitHub (Jul 16, 2020): I have been testing out preview 1.1.1812.0, and while the issue is not as frequent, it still happens with vertical panes.
Author
Owner

@DHowett commented on GitHub (Jul 16, 2020):

Is the character still 0x0f when you’re seeing the issue with vertical panes?

@DHowett commented on GitHub (Jul 16, 2020): Is the character still 0x0f when you’re seeing the issue with vertical panes?
Author
Owner

@edrpls commented on GitHub (Jul 16, 2020):

@DHowett I'm not sure, since it happens very rarely now, it's difficult to debug, so it's not that much of an issue now. I'll try to get more data if next time it happens.

@edrpls commented on GitHub (Jul 16, 2020): @DHowett I'm not sure, since it happens very rarely now, it's difficult to debug, so it's not that much of an issue now. I'll try to get more data if next time it happens.
Author
Owner

@Jessidhia commented on GitHub (Sep 10, 2020):

A similar thing that is hard to consistently reproduce it, and very difficult to actually get a screenshot of it; but sometimes (tmux 3.0a in Terminal 1.3.2382.0), when mouse mode is enabled*, opening the right click menu (holding right mouse button wherever) will draw all the line drawing characters with garbled characters; they look very similar to UTF-8 text being parsed as ISO-8859-1. The terminal does correct itself very quickly, less than 100ms, but if the garbled characters did cause line wrapping to happen, the layout stays broken until one changes panes or tabs.

*: set -g mouse on, which can be input without changing your tmux.conf by using Ctrl+b :

When the garbled line drawing characters from the right click menu happen, any line drawing characters from pane separators will also be shown as random characters until tmux corrects itself.

Note that this is not due to tmux or something else in the system not being in UTF-8 mode; UTF-8 filenames are still correctly printed and displayed. It's only that split second frame that appears to incorrectly decode UTF-8. This also happens, sometimes, with my shell's powerline-based PS1 after starting tmux from scratch: the PS1 will print garbled text instead of powerline characters, and then it'll correct itself before I put any input; but if the extra length from the bad decode(?) causes a line wrap, the tmux status line gets pushed off-screen unless I detach and reattach.


EDIT: after the terminal was left attached overnight, this happened to the tmux status line:
image

The input cursor for the shell is also positioned incorrectly:
image

@Jessidhia commented on GitHub (Sep 10, 2020): A similar thing that is hard to consistently reproduce it, and very difficult to actually get a screenshot of it; but sometimes (tmux 3.0a in Terminal 1.3.2382.0), when mouse mode is enabled*, opening the right click menu (holding right mouse button wherever) will draw all the line drawing characters with garbled characters; they look very similar to UTF-8 text being parsed as ISO-8859-1. The terminal does correct itself very quickly, less than 100ms, but if the garbled characters did cause line wrapping to happen, the layout stays broken until one changes panes or tabs. *: `set -g mouse on`, which can be input without changing your `tmux.conf` by using <kbd>Ctrl+b</kbd> <kbd>:</kbd> When the garbled line drawing characters from the right click menu happen, any line drawing characters from pane separators will also be shown as random characters until tmux corrects itself. Note that this is not due to tmux or something else in the system not being in UTF-8 mode; UTF-8 filenames are still correctly printed and displayed. It's only that split second frame that appears to incorrectly decode UTF-8. This also happens, sometimes, with my shell's powerline-based PS1 after starting `tmux` from scratch: the PS1 will print garbled text instead of powerline characters, and then it'll correct itself before I put any input; but if the extra length from the bad decode(?) causes a line wrap, the tmux status line gets pushed off-screen unless I detach and reattach. --- EDIT: after the terminal was left attached overnight, this happened to the tmux status line: ![image](https://user-images.githubusercontent.com/73085/92834782-65585600-f415-11ea-8053-64049a7c7abd.png) The input cursor for the shell is also positioned incorrectly: ![image](https://user-images.githubusercontent.com/73085/92834912-8d47b980-f415-11ea-9b85-f5ca88675d8d.png)
Author
Owner

@Jessidhia commented on GitHub (Nov 12, 2020):

I just happened to catch this same glitch happening while being completely outside tmux; this is just a regular direct zsh session in WSL2:

image

The glitch happened to coincide with me typing, which is possibly what caused the glitch to stay on screen.

@Jessidhia commented on GitHub (Nov 12, 2020): I just happened to catch this same glitch happening while being _completely outside tmux_; this is just a regular direct `zsh` session in WSL2: ![image](https://user-images.githubusercontent.com/73085/98909920-ced40e00-2505-11eb-8a0a-bea61a3ae63f.png) The glitch happened to coincide with me typing, which is possibly what caused the glitch to stay on screen.
Author
Owner

@DHowett commented on GitHub (Nov 13, 2020):

Whoa. It looks like something disabled UTF-8 handling. You're totally right about that. Tell me, is this under the MSYS2/Cygwin runtime?

@DHowett commented on GitHub (Nov 13, 2020): Whoa. It looks like something disabled UTF-8 handling. You're totally right about that. Tell me, is this under the MSYS2/Cygwin runtime?
Author
Owner

@shuffle2 commented on GitHub (Jan 11, 2021):

Setting locale to en_US
with sudo update-locale LANG=en_US.UTF8
solved the problem for me.
Before there was C.UTF8

Just wanted to note that I was in the same situation and this also "fixed" it for me. Default install of Ubuntu 20.10 in WSL2, using Terminal 1.4.3243.0 from the Store. Before switching to en_US.UTF8 I would sometimes get corruption (mostly when color escape codes were used in weechat, or some combination of tmux, htop, etc).
It does seem like the default should "just work" - but is the issue with Terminal, WSL2's Ubuntu distro, or something else?

After changing to en_US.UFT8 there is still some improper behavior, e.g.:
image
(the "space" in "shuffle2" shouldn't be there)

With C.UTF8, the formatting of the blue URL would get broken and cause random other lines of the window to be overwritten.

The nickname is using a unicode zero-width space: 38433caf31/central/ircclient.py (L108)

edit: actually, there is still some corruption (although not as bad).
A weechat channel with some lines containing escape codes:
image
After changing weechat window to view another channel, some characters remain on screen:
image

ok...last update 😅
After letting weechat run for some time, I am actually still seeing corruption close to or the same as before, so C.UTF8->en_US.UTF8 didn't help as much as I thought.
I also see that the zero-width unicode issue specifically is already tracked in a separate issue on this github repo.

@shuffle2 commented on GitHub (Jan 11, 2021): > Setting locale to en_US > with `sudo update-locale LANG=en_US.UTF8` > solved the problem for me. > Before there was C.UTF8 Just wanted to note that I was in the same situation and this also "fixed" it for me. Default install of Ubuntu 20.10 in WSL2, using Terminal 1.4.3243.0 from the Store. Before switching to en_US.UTF8 I would sometimes get corruption (mostly when color escape codes were used in weechat, or some combination of tmux, htop, etc). It does seem like the default should "just work" - but is the issue with Terminal, WSL2's Ubuntu distro, or something else? After changing to en_US.UFT8 there is still some improper behavior, e.g.: ![image](https://user-images.githubusercontent.com/113063/104142202-5a83e280-536f-11eb-84ff-05035d1a8bee.png) (the "space" in "shuffle2" shouldn't be there) With C.UTF8, the formatting of the blue URL would get broken and cause random other lines of the window to be overwritten. The nickname is using a unicode zero-width space: https://github.com/dolphin-emu/sadm/blob/38433caf317fafb66c46efdbf6bed03fbf9d21c0/central/ircclient.py#L108 edit: actually, there is still some corruption (although not as bad). A weechat channel with some lines containing escape codes: ![image](https://user-images.githubusercontent.com/113063/104145514-1f3be080-537c-11eb-9881-94ed36dd9b59.png) After changing weechat window to view another channel, some characters remain on screen: ![image](https://user-images.githubusercontent.com/113063/104145533-311d8380-537c-11eb-96fd-5c1ce6a3657e.png) ok...last update 😅 After letting weechat run for some time, I am actually still seeing corruption close to or the same as before, so C.UTF8->en_US.UTF8 didn't help as much as I thought. I also see that the zero-width unicode issue specifically is already tracked in a separate issue on this github repo.
Author
Owner

@llchan commented on GitHub (Sep 24, 2021):

This may be a red herring, but it seem that if I ssh to a host with an identical infocmp both inside + outside of tmux, rendering behaves normally --- this rendering issue only happens for me in a tmux running locally (WSL2).

@llchan commented on GitHub (Sep 24, 2021): This may be a red herring, but it seem that if I ssh to a host with an identical infocmp both inside + outside of tmux, rendering behaves normally --- this rendering issue only happens for me in a tmux running locally (WSL2).
Author
Owner

@Gee19 commented on GitHub (Oct 15, 2021):

I haven't seen this issue for the past few months using preview builds but in the last few days it started happening consistently. Always the same setup, 2 horizontal tmux panes with vim in the top pane (split vertically).

This issue went away when I switched to the newest stable release (Windows Terminal v1.10.2714.0).

@Gee19 commented on GitHub (Oct 15, 2021): I haven't seen this issue for the past few months using preview builds but in the last few days it started happening consistently. Always the same setup, 2 horizontal tmux panes with vim in the top pane (split vertically). This issue went away when I switched to the newest stable release (Windows Terminal v1.10.2714.0).
Author
Owner

@l1n3n01z commented on GitHub (Jan 1, 2022):

I have 1.11.3471.0
For the purposes of this test I used both Cascadia Mono and Consolas.
I can reproduce this problem simply by doing line selection in a clean neovim through tmux

@l1n3n01z commented on GitHub (Jan 1, 2022): I have 1.11.3471.0 For the purposes of this test I used both Cascadia Mono and Consolas. I can reproduce this problem simply by doing line selection in a clean neovim through tmux
Author
Owner

@l1n3n01z commented on GitHub (Jan 1, 2022):

I have 1.11.3471.0 For the purposes of this test I used both Cascadia Mono and Consolas. I can reproduce this problem simply by doing line selection in a clean neovim through tmux

This may be a tmux configuration issue. The problem seems to be fixed after I set
set-window-option -g utf8 on
in .tmux.conf
after seeing this issue https://github.com/kovidgoyal/kitty/issues/2047

@l1n3n01z commented on GitHub (Jan 1, 2022): > I have 1.11.3471.0 For the purposes of this test I used both Cascadia Mono and Consolas. I can reproduce this problem simply by doing line selection in a clean neovim through tmux This may be a tmux configuration issue. The problem seems to be fixed after I set `set-window-option -g utf8 on` in **.tmux.conf** after seeing this issue https://github.com/kovidgoyal/kitty/issues/2047
Author
Owner

@glowinthedark commented on GitHub (Mar 14, 2022):

Looks like that the corruption happens when the minute changes, so it's somehow related to the time display.

a few months later... — happened to have the same tmux session being displayed on two different screens from two different OS's and noticed that only the macos iTerm2 session was suffering from mangled display. Same session in Apple's ootb Terminal.apps is totally fine.

@glowinthedark commented on GitHub (Mar 14, 2022): Looks like that the corruption happens when the minute changes, so it's somehow related to the time display. a few months later... — happened to have the same tmux session being displayed on two different screens from two different OS's and noticed that only the macos iTerm2 session was suffering from mangled display. Same session in Apple's ootb Terminal.apps is totally fine.
Author
Owner

@zadjii-msft commented on GitHub (Mar 14, 2022):

for x-linking purposes: #6987

@zadjii-msft commented on GitHub (Mar 14, 2022): for x-linking purposes: #6987
Author
Owner

@zadjii-msft commented on GitHub (Jan 13, 2025):

Hey it's been years since we've heard anything about this - is anyone still hitting this on 1.22 Preview/? That version has a wholly re-written conpty that does away with a lot of old bugs

@zadjii-msft commented on GitHub (Jan 13, 2025): Hey it's been years since we've heard anything about this - is anyone still hitting this on 1.22 Preview/? That version has a wholly re-written conpty that does away with a _lot_ of old bugs
Author
Owner

@l1n3n01z commented on GitHub (Jan 14, 2025):

Hey it's been years since we've heard anything about this - is anyone still hitting this on 1.22 Preview/? That version has a wholly re-written conpty that does away with a lot of old bugs

I fixed the issue at the time by setting utf8 in tmux. I am using 1.22 and not getting any issues at all. I have had issues in other terminals (Alacritty and WezTerm) with weird fonts (half-width fonts and some other issues) that have left tmux garbled on Windows but not in Windows Terminal.

An aside, it would be really nice for the terminal ecosystem on windows, if the authors of those other terminals (and wsltty as well) had a better documented way of using conpty correctly. Usually when issues come up with other terminals, it's almost always windows specific and it's almost always because of incorrect conpty or incorrect use of conpty.

@l1n3n01z commented on GitHub (Jan 14, 2025): > Hey it's been years since we've heard anything about this - is anyone still hitting this on 1.22 Preview/? That version has a wholly re-written conpty that does away with a _lot_ of old bugs I fixed the issue at the time by setting utf8 in tmux. I am using 1.22 and not getting any issues at all. I have had issues in other terminals (Alacritty and WezTerm) with weird fonts (half-width fonts and some other issues) that have left tmux garbled on Windows but not in Windows Terminal. An aside, it would be really nice for the terminal ecosystem on windows, if the authors of those other terminals (and wsltty as well) had a better documented way of using conpty correctly. Usually when issues come up with other terminals, it's almost always windows specific and it's almost always because of incorrect conpty or incorrect use of conpty.
Author
Owner

@microsoft-github-policy-service[bot] commented on GitHub (Jan 18, 2025):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@microsoft-github-policy-service[bot] commented on GitHub (Jan 18, 2025): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**. <!-- Policy app identification https://img.shields.io/static/v1?label=PullRequestIssueManagement. -->
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5654