Sixels are not cleared properly inside tmux

[veltza]

Description

When previewing images inside tmux, sixels are not cleared correctly between renders. Instead of replacing the previous image, the new image is rendered over the previous one:

Analysis

I have analyzed the issue with my st fork and I have gotten some interesting results.

When previewing images outside of tmux, lf (Tcell v3) emits a large number of escape sequences. Many of these are CUP sequences (ESC [ y ; x H) that move the cursor in the preview area while it is being cleared. This behavior is expected and indicates that everything is working correctly.

Click to expand

ESC[?2026h
ESC[58;106H
ESC[?25l
ESC[1;26H
ESC[m
ESC[1m
ESC[1;30H
ESC[1;32H
ESC[2;2H
ESC[m
ESC[32m
ESC[1m
ESC[2;37H
ESC[m
ESC[3;2H
ESC[m
ESC[32m
ESC[1m
ESC[7m
ESC[3;37H
ESC[m
ESC[4;37H
ESC[5;37H
ESC[6;37H
ESC[7;37H
ESC[8;37H
ESC[9;37H
ESC[10;37H
ESC[11;37H
ESC[12;37H
ESC[13;37H
ESC[14;37H
ESC[15;37H
ESC[16;37H
ESC[17;37H
ESC[18;37H
ESC[19;37H
ESC[20;37H
ESC[21;37H
ESC[22;37H
ESC[23;37H
ESC[24;37H
ESC[25;37H
ESC[26;37H
ESC[27;37H
ESC[28;37H
ESC[29;37H
ESC[30;37H
ESC[31;37H
ESC[32;37H
ESC[33;37H
ESC[34;37H
ESC[35;37H
ESC[36;37H
ESC[37;37H
ESC[38;37H
ESC[39;37H
ESC[40;37H
ESC[41;37H
ESC[42;37H
ESC[43;37H
ESC[44;37H
ESC[45;37H
ESC[46;37H
ESC[47;37H
ESC[48;37H
ESC[49;37H
ESC[50;37H
ESC[51;37H
ESC[52;37H
ESC[53;37H
ESC[54;37H
ESC[55;37H
ESC[56;37H
ESC[57;25H
ESC[57;44H
ESC[57;48H
ESC[57;103H
ESC[58;106H
ESC[?25l
ESC[?2026l
ESC[?2026h
ESC[2;37H
ESC[30;37H
ESC[?2026l
ESC[?2026h
ESC[58;106H
ESC[?25l
ESC[58;106H
ESC[?25l
ESC[?2026l
ESC[?2026h
ESC[58;106H
ESC[?25l
ESC[58;106H
ESC[?25l
ESC[?2026l

Inside tmux, however, the behavior changes dramatically. The terminal emulator receives only a small number of escape sequences, including just a few CUP sequences. This suggests that the preview area is not being cleared at all. Something is clearly going wrong here.

Click to expand

ESC[1;26H
ESC[1m
ESC[C
ESC[C
ESC[2;2H
ESC[32m
ESC[C
ESC[0m
ESC[3;2H
ESC[32m
ESC[1m
ESC[7m
ESC[C
ESC[0m
ESC[52;101H
ESC[56;25H
ESC[15C
ESC[2C
ESC[54C
ESC[C
ESC[2;37H
ESC[0m
ESC[?12l
ESC[?25h
ESC[?1006l
ESC[?1000l
ESC[?1002l
ESC[?1003l
ESC[1;1H
ESC[1;57r
ESC[56;105H
ESC[?25l

For comparison, lf r41 (Tcell v2) produces these escape sequences inside tmux.

Click to expand

ESC[34m
ESC[1m
ESC[H
ESC[39m
ESC[0m
ESC[2;1H
ESC[32m
ESC[1m
ESC[0m
ESC[3;1H
ESC[32m
ESC[1m
ESC[7m
ESC[0m
ESC[4;1H
ESC[5;1H
ESC[6;1H
ESC[7;1H
ESC[8;1H
ESC[9;1H
ESC[10;1H
ESC[11;1H
ESC[12;1H
ESC[13;1H
ESC[14;1H
ESC[15;1H
ESC[16;1H
ESC[17;1H
ESC[18;1H
ESC[19;1H
ESC[20;1H
ESC[21;1H
ESC[22;1H
ESC[23;1H
ESC[24;1H
ESC[25;1H
ESC[26;1H
ESC[27;1H
ESC[28;1H
ESC[29;1H
ESC[30;1H
ESC[31;1H
ESC[32;1H
ESC[33;1H
ESC[34;1H
ESC[35;1H
ESC[36;1H
ESC[37;1H
ESC[38;1H
ESC[39;1H
ESC[40;1H
ESC[41;1H
ESC[42;1H
ESC[43;1H
ESC[44;1H
ESC[45;1H
ESC[46;1H
ESC[47;1H
ESC[48;1H
ESC[49;1H
ESC[50;1H
ESC[51;1H
ESC[52;1H
ESC[53;1H
ESC[54;1H
ESC[55;1H
ESC[36m
ESC[56;1H
ESC[39m
ESC[52;84H
ESC[53;37H
ESC[54;37H
ESC[55;37H
ESC[56;1H
ESC[36m
ESC[C
ESC[39m
ESC[C
ESC[C
ESC[2C
ESC[C
ESC[C
ESC[C
ESC[C
ESC[C
ESC[49C
ESC[2;37H
ESC[0m
ESC[?12l
ESC[?25h
ESC[?1006l
ESC[?1000l
ESC[?1002l
ESC[?1003l
ESC[1;1H
ESC[1;57r
ESC[1;1H
ESC[34m
ESC[1m
ESC[39m
ESC[2;3H
ESC[?25l
ESC[0m
ESC[H
ESC[34m
ESC[1m
ESC[39m
ESC[2;3H
ESC[32m
ESC[3;3H
ESC[7m
ESC[56;1H
ESC[0m
ESC[36m
ESC[C
ESC[39m
ESC[C
ESC[C
ESC[2C
ESC[C
ESC[C
ESC[C
ESC[C
ESC[C
ESC[49C

If I had to guess, I’d say the issue is with Tcell v3, since as far as I know, lf doesn’t behave any differently inside tmux.

[CatsDeservePets]

I strongly believe it has to do with all of these sensitisation recently.

[CatsDeservePets]

@valoq Would you look into this?

[valoq]

This is probably related to PR #2474, which removed the tmux-specific rounding of sixel image height
The fix probably involves restoring that rounding for the locked region while keeping the bounds check from PR #2474 intact, so both bugs stay fixed?

Im fairly certain this isn't related to any changed in sixel, those would break regardless of use in tmux

[CatsDeservePets]

This is probably related to PR #2474, which removed the tmux-specific rounding of sixel image height The fix probably involves restoring that rounding for the locked region while keeping the bounds check from PR #2474 intact, so both bugs stay fixed?

I highly doubt it. This workaround was added (by @veltza, funnily enough) as a reaction to weird changes in tmux. Those changes were reverted several months later in version 3.6. However, lf did keep those changes until recently, even though they were only valid for a very short amount of time anyway.

Im fairly certain this isn't related to any changed in sixel, those would break regardless of use in tmux

Terminal multiplexers like tmux use private escape sequences to pass communication between child processes and the host terminal. That is the reason tools like chafa have specific tmux related passthrough flags. Also, the report even states that lf no longer passes all the escape sequences.

@veltza If you want to use git bisect:

• chore!: change to use v3 of Tcell #2286 was the jump to tcell v3
• fix: remove sixel height override for tmux #2474 reverted tmux specific code

If none of these two caused the regression, there are multiple PRs related to filtering out escape sequences.

[veltza]

• chore!: change to use v3 of Tcell #2286 was the jump to tcell v3

That caused the regression. Something is now preventing the preview window from clearing when using sixels in tmux.

[valoq]

Terminal multiplexers like tmux use private escape sequences to pass communication between child processes and the host terminal. That is the reason tools like chafa have specific tmux related passthrough flags. Also, the report even states that lf no longer passes all the escape sequences all.

You are probably right. I did try to fix this by letting the valid tmux sequences pass in #2582

@veltza can you please check if this patch solves the issue for you? #2582

[veltza]

@veltza can you please check if this patch solves the issue for you? #2582

Your patch doesn't change anything.

I suspect that screen.LockRegion() in Tcell v3 doesn't work properly with sixels in tmux.

[valoq]

I suspect that screen.LockRegion() in Tcell v3 doesn't work properly with sixels in tmux.

@gdamore Probably another tcell v3 issue

[valoq]

@veltza can you try this patch in combination with #2582 please?

it fixed the issue for me and confirms that there are two misisng pieces, both #2582 and a tcell bug

[veltza]

@veltza can you try this patch in combination with #2582 please?

Your patch seems to be missing.

it fixed the issue for me and confirms that there are two misisng pieces, both #2582 and a tcell bug

I don't use passthrough in tmux, so #2582 doesn't fix anything for me. Why would I need to use passthrough when tmux can handle sixels anyway?

[valoq]

Sorry, I forgot to attach it.
lf-sixel-clear-workaround.patch

Note that without #2582 sixel images didnt show for me at all in tmux

[veltza]

lf-sixel-clear-workaround.patch

I can confirm that this patch works. It clearly demonstrates that this is another Tcell v3 issue.

Note that without #2582 sixel images didnt show for me at all in tmux

I still don’t need #2582 because my tmux has sixel support.