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

Created on 16 Jun 2016  路  7Comments  路  Source: microsoft/vscode

  • 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.

editor-rendering feature-request

Most helpful comment

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.

All 7 comments

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.

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?

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 馃憥

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.

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

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...

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.

Was this page helpful?
0 / 5 - 0 ratings