Randomly added / inserted numbers on startup

[Bios-Marcel]

Version: 1.0.0
Terminal: Wezterm

This does seem to be somehow related to usage within Wezterm, but I don't know where the issue lies. I do not have such behaviour in other shell applications.

wezterm-gui_QBTKLcIn9I.mp4

I recorded a video of it. It only happens after opening it twice it seems.

[lhecker]

This is most likely a leftover of the VT responses from WezTerm. The best way to investigate may be to modify this spot to log the received text into a file on disk:

edit/src/sys/windows.rs

Lines 361 to 362 in d832058

	text.shrink_to_fit();
	Some(text)

I suspect that this may be a race condition of some sort (not inside edit, but between edit and the terminal).

[irmackenzie]

I see this added to the start of the opened text file when running edit in git-bash on Windows:

;0;rgb:0000/0000/0000;1;rgb:d4d4/2c2c/3a3a;2;rgb:1c1c/a8a8/0000;3;rgb:c0c0/a0a0/0000;4;rgb:0000/5d5d/ffff;5;rgb:b1b1/4848/c6c6;8;rgb:6060/6060/6060;9;rgb:ffff/7676/7676;10;rgb:0000/f2f2/0000;11;rgb:f2f2/f2f2/0000;12;rgb:7d7d/9797/ffff;13;rgb:ffff/7070/ffff;14;rgb:0000/f0f0/f0f0;15;rgb:ffff/ffff/ffff

Edit: I pulled the latest and now get this text

;0;rgb:0000/0000/0000

And edit shows a "go to line/column" popup populated with ffff/ffff/ffff

[lhecker]

I do believe everyone here that this is a real issue, because I've seen this exact behavior in other projects a few times already. The only problem is that I cannot reproduce it with Windows Terminal.

[Bios-Marcel]

If you give me debug code, i can try giving you logs or so. I don't know Rust :D

[lhecker]

Logs would not be useful in figuring this out, unfortunately.

[DHowett]

Well, to be fair... if it reproduces on Windows Terminal a log from the debug tap might be helpful! Just to see if there's an issue in input generation.

[lhecker]

This is trivially reproducible in WezTerm, so it may be specific to the older ConPTY it ships with. I guess? In WSL you can test it with:

sh -c 'printf "\e]4;0;?;1;?;2;?;3;?;4;?;5;?;6;?;7;?\x07\e]4;8;?;9;?;10;?;11;?;12;?;13;?;14;?;15;?\x07\e]10;?\x07\e]11;?\x07\e[c"; read >/dev/null'

The expected response should be quite long. In WezTerm I get:

^[[?61;6;7;22;23;24;28;32;42c555^[\

It also doesn't react the first time I press Enter. I faintly remember an OSC ordering issue with Windows Terminal / ConPTY but I can't find it.

[ekmpspete]

I've experienced this issue when using windows terminal (1.22.11751.0) and running msedit (1.2.0) within a docker container built from "mcr.microsoft.com/windows/servercore:ltsc2022".

I'm seeing the numbers "626" prepended to the file contents.

Leonard Hecker (@lhecker) Hope this help you to replicate the issue.

[atsyplenkov]

I am experiencing the same in wezterm (20240203-110809-5046fc22) and edit (1.2.0) on Windows 10. No matter the shell (cmd, powershell, wsl), edit adds the 626 at the beginning of the file. See cast below

However, the same wezterm works fine on Fedora 42 Workstation

[lhecker]

As mentioned above, wezterm uses an older version of something called ConPTY (which we maintain). It used to be somewhat buggy and has received numerous bug fixes over the last year. I don't believe they use the latest version yet. You can steal OpenConsole.exe from a recent Windows Terminal Canary build and replace the same file in your wezterm folder.

Peter Wrigley (@ekmpspete) I don't have docker installed right now, but I suspect they also use ConPTY, but an even older version installed as part of the OS.

I suspect that this will be a recurring issue and likely the only way to hotfix it is by adding a literal sleep() in the startup path of edit lol. 🥲

[j4james]

I suspect that this will be a recurring issue and likely the only way to hotfix it is by adding a literal sleep() in the startup path of edit lol. 🥲

Leonard Hecker (@lhecker) Another solution might be to allow edit to accept OSC query responses out of sequence. You don't necessarily need to process them - if the DA1 response is received before the palette responses, you can just drop them when they eventually do arrive. Worst case is you lose out on the palette detection. The important thing is to not treat the OSC introducer as an Alt+] keystroke, and keep consuming the response until the string terminator. That's assuming the responses don't get intertwined in some way - I can't remember if that's the case.