Lines greater than 1024 chars long crash the editor on Windows 11.

[professorbee]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

Lines greater than 1024 characters break windows. Steps to reproduce:

1. Create a file in another text editor with a line containing 1025 characters.
2. Open in editor.
3. Watch it crash.

Here's the file I used: test.txt

Environment

Zed: v0.135.0 (Zed Dev d64106e)
OS: Windows 10.0.22631
Memory: 31.7 GiB
Architecture: x86_64

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

Zed.log

[pidjan]

i can confirm that this issue also occurs for me on the latest commit: 6a64b73.
OS: Windows 11 22631.2861
Memory: 32GB
Arch: x86_64
Zed.log
i created a new text file in Zed and copy-pasted line containing 1025 characters from your test.txt - crashed immediately, file was not saved. exit code: 0xffffffff

[someone13574]

It seems to break (but not crash) on Linux as well. You can not scroll past 1024 horizontally and if you insert anything it simply goes off the visible area.

[someone13574]

Found the problem. I used git bisect to find that #11080 (this commit specifically) changes the behavior of the soft-wrap mode "none" to not wrap for very long lines, which doesn't respect MAX_LINE_LEN (which is set to 1024), causing a crash (or clipping if on linux and mac) when the line length exceeds that instead of wrapping at 512. Temporarily, you can fix this by adding "soft_wrap": "prefer_line" to your settings.json. I'm not sure how @SomeoneToIgnore want's to deal with it long term if no wrapping is required for git hunks but setting “prefer line” should work for now.

This long line wrapping seems like it was added for this exact reason (fixing clipping) in #866 which was a response to #834

[SomeoneToIgnore]

PreferLine variant is supposed to be the new default, as the one being called None before — the only place current None is intended to be used is git diff hunks.

So, I see two problems with Windows impl:

• usage of None instead of PreferLine
• panics on long lines

I would not want to deal with Windows anyhow special on this regard, IMO it's supposed to work with the long lines too disregarding of the wrapping mode.

[JunkuiZhang]

This surprised me. I tested it, and when calling layout_line, the input text parameter has only 1024 characters, but the FontRun parameter indicates there are 1025 characters, causing a panic when accessing text[index]. I think the issue lies in the input parameter when calling layout_line, but it can also be easily fixed in DirectWrite. Should I fix it on the DirectWrite side or where layout_line is called?

[JunkuiZhang]

#11536 should fix this, I tested it on my laptop.