Long Text longer than 10000 letters wrapped with [...]

[lllopo]

• VSCode Version: 1.3.0-insiders
• OS Version: Win 10

Steps to Reproduce:

1. Open a file with a very long line - over the limit of 10000
2. Position the cursor at the start of the line in question
3. Press 'End' keyboard key

Result - the 'End' key does nothing, while it rather has to go to the end of the trimmed/loaded part of the line.

All-in-all, I must say the approach to treating long lines is one of the worst shortcomming of VS Code (along with not being able to load big files at all). This approach makes the editor totally unusable for touching minified scripts and css for example, so I'd rather say you have to think of improving the performance and removing this serious limitation.

[alexdima]

This is a limitation (since 5+ years) of our not having horizontal virtualization (in the same way we have vertical virtualization). We don't have horizontal virtualization because we leave it up to the browser to run the font layouting.

In other words:

• when there is a large line, and word wrapping is off, we must paint the entire line since we cannot virtualize it because we didn't implement the Unicode layouting rules in JS (i.e. we don't know where bi-di text is, how the viewport intersects with the text, etc. etc.)
• if the line is very large, this will cause freezes, depending on the line size. Browsers don't deal well with dumping a lot of dom nodes / text for a line.
• in the case of such files (which are dominated by long lines), we forcefully go to word wrap on and an explicit user gesture is needed to turn off word wrap.
• additionally, we stop rendering a line after 10k characters and render "..." to indicate that there is more text. The cursor and all editing operations function normally on the extra characters, but they do not get rendered.
• the current recommendation is to turn on word wrapping if the intent is to edit past the 10k limit or change the limit via the "hidden" setting "editor.stopRenderingLineAfter" which is equal to 10000 by default, but which can be changed to -1 to never stop rendering. But then freezes/lagging might occur.

[Zooce]

It took me a hell of a lot of digging to find this post. Is there any chance of making the "hidden" setting "editor.stopRenderingLineAfter" not "hidden?" Also, the autowrap when you set this to -1 is kind of a pain. I already had to modify a "hidden" setting to force the behavior I wanted - now I have another step in the way?

[peheje]

Thanks Zooce, works even if editor tells you it can't recognize that setting.

The more I use vscode, the more I find these limitations that just for a minute stops my day 👎

[adjenks]

User story: I discovered this today when I wanted to delete a single character near the end of an extremely long line of text. I was initially confused when I hit the end key the screen didn't move but the cursor column number was really high. I found that I could toggle text wrap and then scroll way down instead. I did figure out how to work around it, but it could have been more intuitive.

[matteoATsametab]

On version 1.41.1 you can set Editor: Word Wrap to on inside preferences/settings

[tyeth]

Same issue, stupidly long long of data from a generated script, >400k characters.
It would be better if the user is warned of a file containing lines over 10k (or ideally over the users setting so taking into account -1 etc) and then prompted to let vscode turn on wrapping automatically for files containing excessively long lines...

[caesarsol]

I agree with @tyeth, this issue is too unexpected to be so hidden!
Users just see the ... at the end of the 10k line but nowhere it's explained that >10k lines are impossible to render. An alert or toaster would be helpful.

[rendomnet]

this is annoying as hell and very bad UX

[ugurcok]

Why is the over-limit warning coming up without doing anything?

[adjenks]

@ugurcok What do you mean "without doing anything?" Is your document empty?
Show the error message and describe the properties of the document and it would help the developers.
Maybe you have a document with 10,000+ whitespace characters in a row? :)

[martin-braun]

If the file doesn't just have very long lines, but also a ton of lines, word wrap is disabled and it becomes a dead end, unless I set "editor.stopRenderingLineAfter" to -1 and start the lag fest. VSCode is not the right editor to deal with very large files, apparently.

[mparsakia]

Ran into this issue while embedding a long base64 string as a background image in a css file. Looks like syntax highlighting also disabled for that line too. The first few pastes of the base64 string completely didn't render (as in, vscode added the "..." and treated that as the text).

[blueberry6401]

Microsoft always comes with genius solution.

[jwaffe75]

This is annoying for me too, bumping for the sake of visibility / metrics (I think Microsoft weights how often an issue gets comments)

This is not great UX and I suggest the following alternatives:

• Show a warning if a line is longer than 10k
• Have unlimited lines be automatically enabled if a file has lines longer than 10k
• Don't hide editor.stopRenderingLineAfter, why was this hidden? VSCode pretends this setting does not even exist
• Not only this this setting not searchable in settings, it's treated as an "unknown configuration setting" when I edit it manually into settings.json
• Perhaps enable it by default, and disable whatever part of VSCode is causing the performance problem (syntax highlighting? language parsing?) when it becomes an issue. I think VSCode does this already when I open binary files, why can't it do this for text files?
• I would be surprised if parsing a JSON file is all that heavyweight, since it's pure data, if it is, I'd rather just opt out of whatever this "smart parsing" is doing and have VSCode show me the whole file with untruncated lines.

Word wrap is not a workaround

• I may want to look at a file as it is
• I know working with massive lines is annoying (nobody likes scrolling horizontally), but with files that have very massive lines it might be better than the alternative

Preemptively responding to "your code should not be this long anyway"

• I know that massive lines on code files is a bad idea, but I'm not working with a .c code file with 10000 char long lines, this is a .json data file
• I know it's probably bad practice to have a .json data file this big, but it's not my json file
• In my case I'm trying to rip an error message out of a .json file that decided it was a good idea to encode an error message in one long line with '\n' characters separating everything
• If you now want to say "well the program that generated this is bad", then... well, please be a bit more pragmatic. This is a program by a major company, and there's no real alternative.
• VSCode is a text editor, a tool, for helping me work with situations like this.

This is not an unsolvable problem

• Notepad++ can do this
• I realize VSCode is Javascript and maybe was not designed to do this
• Some dev while writing this realized that there was a static limit in the drawing space (10k characters)
• It would be great if that static limit was removed, but even if it can't be, I think there's a smarter solution instead of this "quick hack"

[skygate2012]

It's amazing how this issue still hasn't been resolved, after over 10 years. At least implement a workaround that could enable users to edit the end of the line.

[jflambert]

How about letting us click the [...] to expand the full line?

[StingyJack]

This also affects data pasted into the editor, like a base 64 encoded JWT I would need to use for some admin/maintenance scripts. if I copied an extra " before pasting i cant fix it after pasting.

[cristian-eriomenco]

Copy Pasting JSONs is a trivial requirement. Why there are still arguments about this? (facepalm)

[RokeJulianLockhart]

How do I modify "editor.stopRenderingLineAfter"?

[martin-braun]

@BEEDELLROKEJULIANLOCKHART

[RokeJulianLockhart]

{
    "editor.fontFamily": "",
    "workbench.iconTheme": null,
    "window.autoDetectColorScheme": true,
    "scm.inputFontFamily": "",
    "debug.console.fontFamily": "",
    "markdown.preview.fontFamily": "",
    "editor.formatOnType": true,
    "terminal.integrated.customGlyphs": false,
    "workbench.colorTheme": "Default High Contrast",
    "workbench.preferredDarkColorTheme": "Default High Contrast",
    "workbench.preferredLightColorTheme": "Default High Contrast Light",
    "files.autoSave": "onFocusChange",
    "editor.renderWhitespace": "all",
    "editor.tabSize": 2,
    "gitlab.debug": true,
    "security.workspace.trust.untrustedFiles": "open",
    "terminal.integrated.defaultProfile.osx": "",
    "terminal.integrated.shellIntegration.history": 1e+308,
    "scm.repositories.visible": 0,
    "workbench.commandPalette.history": 1e+308,
    "workbench.localHistory.maxFileEntries": 1e+308,
    "workbench.localHistory.maxFileSize": 1e+308,
    "workbench.localHistory.mergeWindow": 1e+308,
    "interactiveWindow.restore": true,
    "terminal.external.windowsExec": "alacritty",
    "terminal.integrated.enableBell": true,
    "terminal.external.linuxExec": "alacritty",
    "terminal.external.osxExec": "alacritty",
    "terminal.integrated.defaultProfile.windows": "",
    "editor.fontSize": 13,
    "debug.console.fontSize": 13,
    "markdown.preview.fontSize": 13,
    "terminal.integrated.fontSize": 13,
    "tabnine.experimentalAutoImports": true,
    "tabnine.receiveBetaChannelUpdates": true,
    "editor.semanticHighlighting.enabled": true,
    "git.autofetch": true,
    "files.hotExit": "onExitAndWindowClose",
    "todo-tree.general.debug": true,
    "todo-tree.general.enableFileWatcher": true,
    "todo-tree.general.tags": [
        "BUG",
        "HACK",
        "FIXME",
        "TODO",
        "XXX",
        "[ ]",
        "[x]",
        "Remediate"
    ],
    "git.confirmSync": false
}

is the content of mine. "editor.stopRenderingLineAfter" is not present. Should I add it?

@martin-braun, I don't know what that depicts. It depicts Control+Shift+P.