Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why does VS Code keep turning off my 'word wrap' setting?

While working in VS Code I've noticed every so often (sometimes as frequently as every few minutes) that it will turn my word wrap setting off under the 'view' tab, and it's getting pretty frustrating having to re-enable it multiple times during my work session.

Any idea why?

I'm not closing the app. At most, I'm only switching back from Chrome to the editor, or between open files in the editor. However it's constantly turning off my word wrap. Only that setting too, no others.

Any info is greatly appreciated.

like image 858
blakedoghyian Avatar asked Feb 02 '26 10:02

blakedoghyian


1 Answers

Microsoft answered this here: https://github.com/microsoft/vscode/issues/21124#issuecomment-308644030

Copy and pasted below:

Yes, this is a "by design" behaviour to workaround a short-coming we have.

  • The editor is vertically virtualized (i.e. only the visible lines in the viewport are inserted to the DOM)
  • However, the editor is not horizontally virtualized (i.e. if a line is visible, it is sent in its entirety to Chromium for painting)
    • We don't do horizontal virtualization because that would involve us reading the font information, and implementing Unicode layouting + font layouting rules on our side, in our JS runtime, across OSes. Today, we leave it up to the browser to layout the text (think e.g. RTL, bidi text, etc.). Also, any change in the layouting algorithm w.r.t. the painting algorithm would yield many bugs, so we would need to also paint all the characters by ourselves.
  • So if a long line is visible in the viewport, we give Chromium the entire line. Chromium ofcourse paints only the visible parts, but it has to deal with the entire line. Unfortunately, if the line is very long, this causes Chromium to slightly freeze, which makes it a very bad experience when scrolling around these long lines.
  • As a workaround, we have implemented a heuristic where we try to identify "minified" files, i.e. files that have very long lines are highly atypical for source code and possibly represent that a resource has been inlined in the source code or that we are dealing with a CSS/JS/etc. minified file.
  • Our heuristic consists of counting characters that sit on regular lines vs. characters that sit on long lines. A long line is a line with more than 10k characters. If more than 50% of the file's characters sit on long lines, then we consider the file to be a "minified" file.
  • In the case of such files, which we call "dominated by long lines", we will wrap the file to protect against the freezes I mentioned above. By freezes I mean that sometimes painting a frame in the editor could take more than >20-30ms, which quickly becomes noticeable, as the large line goes outside the viewport or goes inside, but of course depends on the actual line, etc.
  • The only way to unwrap such a file is current via alt+z or the menu or the special icon that appears next to the editor title area (actions) only in such cases and the unwrapping is temporary for the current window lifecycle.

I'm sorry for the funny experience that looks like a bug, but it is a (perhaps too-involved) workaround to avoid freezes/pauses.

like image 195
CubeOfCheese Avatar answered Feb 03 '26 22:02

CubeOfCheese



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!