The exact same issue exists for inline breakpoints. Taken from #84911 (comment)

Attaching a gif for reference:

Another screenshot from #76458

@alexdima, at this point I don't understand what this issue is...

Is it about supporting word-wrapped inline text decorations or just not showing scrollbars for them?

@usernamehw

Wrapping points (the locations inside a line where to break it into multiple lines) are computed using only the text of the line.

So for the following line, wrapping points are computed by looking at the following text:

When configuring the editor to wrap at column 34 for example, the editor computes that a good line break location is after f3. This looks reasonable and no line is going above 34 columns:

But when changing the language mode to CSS, which adds inline decorations (the color boxes), the wrapping points are computed in exactly the same way as before (without knowledge about the color boxes), so the wrapping point will again be after f3. But note how the text overflows column 34 because the color boxes are added after the fact:

I'd honestly prefer it if the text decorations could appear above the arguments they're referring to, in an even smaller font. Might changing the display like that be easier than fixing this bug?

@dyaso it's not that simple. There's much more different types of code decorators than colors that break word wrapping. Debugger information, variables type helpers, etc. - it's impossible to put them around the code because it would interfere with another code out there. Or it would have to be really small, almost unreadable. The best solution would be to activate wrapping after all decorators have been loaded, but with many of them being loaded by custom modules I assume it must be very hard to come up with a universal fix.

@SharakPL Sorry for bothering you, i was referring to the textual type inferences and argument names rust-analyzer provides, which as well as breaking word wrap make it harder to read what i've written -- i'd prefer them to be almost unreadably small tbh, since i only want + need to read them when scrutinizing something very closely. I'll try disabling text inlay hints and relying on mouseovers for now.

Also user of rust-analyzer, and my workaround is to set the Word Wrap Column really low, around 30+% lower than needed.
If this fix is unfeasible, I could live with a minimum Word Wrap Column and a maximum one, where the minimum would be used at first, and then later, after inline textual insertions, if it wouldn't pass the maximum one, perhaps the "line breaks" could be removed? Would that be more feasible to implement?

Pretty disappointing that this basic bug is still not fixed. I use VS Code also as text editor but maybe I need to look for alternatives. For now, my workaround is:

• disable the minimap in the language specific settings for Markdown or plain text (editor.minimap.enabled)
• disable gitLens.toggleLineBlame which unfortunately is possible only on workspace-level

You can disable the GitLens blame at any level (user/workspace/folder). Check out the interactive setting ui (GitLens: Open Settings from the command palette)

You're right - what I wanted to say (but didn't) was: You can't change GitLens settings in the language specific settings.

Mind opening an issue for that on the GitLens repo. Could be quite valuable outside of this issue as well.

I use VS Code for writing TeX and I have come across this text-wrapping bug. Thanks for the tips about disabling Gitlens blame - that has sorted things for me at least temporarily. Annoying that one has to do this however as I quite like that integration.

This issue has been open for ~6 years...

It seems like more comments and complaints are the only way to get things resolved, more visibility and interactions the better I guess.

I really don't understand how any company can have issues of this age without prioritising them...

Indeed. It's clearly a bug, not a "feature request" 🙄

Guess it must be hard to fix so it's being back-burnered indefinitely

Related(?) Stack Overflow question with the LaTeX-Workshop extension: How can I adjust the position and appearance of chktex linting in VS Code?

I'm also having this issue, does anyone know a workaround?

@peywan if it's such a minor fix then fix it 😉

This is quite annoying when using Tailwind, where lines get quite long, but word wrap's useless because the color decorators offset it...

I've run into this issue as well. Maybe Gitlens has created a workaround aside from just disabling line blame...

This has been a known and documented issue for more than 5 years. When we will see a solution?

This has been a known and documented issue for more than 5 years. When we will see a solution?

Never! Let's make this the longest standing issue :)

This has been a known and documented issue for more than 5 years. When we will see a solution?

Never! Let's make this the longest standing issue :)

Let's not. This issue is really annoying and makes working in a codebase actively harder for no real reason.

I had to disable every extensions that post-adds text for this reason ! This bug is still very annoying, yes...