Vscode: Inline text adornments break word wrapping

[SharakPL]

• VSCode Version: 1.15.1
• OS Version: Windows 10 x64

Steps to Reproduce:

1. Settings:

    "editor.wordWrap": "on",
    "css.colorDecorators.enable": true

1. Code example:

   .form-control:focus { border-color: #141d36; box-shadow: 0 1px 1px rgba(0, 0, 0, 0.075) inset, 0 0 4px rgba(165,128,57,0.6); -webkit-box-shadow: 0 1px 1px rgba(0, 0, 0, 0.075) inset, 0 0 4px rgba(165,128,57,0.6); }

With colorDecorators disabled word wrapping works fine. After enabling it wordWrap completely ignores the width of added decorators and wrapes the code as they are not there what makes parts of the code to be pushed out of viewport.

I think it would be better to just underline the colors accordingly instead adding new elements next to it.
Also it would be great to add some margin between wrapped code and minimap (or whatever is on the right).

Reproduces without extensions: Yes

Edit: Added a screenshot to demonstrate the issue:

[alexdima]

The exact same issue exists for inline breakpoints. Taken from https://github.com/microsoft/vscode/issues/84911#issuecomment-554346833

---

Attaching a gif for reference:

[alexdima]

Another screenshot from #76458

[usernamehw]

@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?

[alexdima]

@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:

[SharakPL]

@alexdima the issue is to have the code actually wrapped with "editor.wordWrap": "on", so no horizontal scrollbars. Workaround would be to add some margin on the right and have the code overflow it, but the only fix I can imagine that would really work is to __not use inline decorations__. They should not be part of the code flow but put above it or they should have width = 0 and be made visible with outline/text-shadow/box-shadow/background - anything that is not disturbing the flow.

[trevyn]

Ok, this is starting to drive me batty. I use rust-analyzer, which uses inline decorations to show inferred type annotations, and I tend to use narrow, word-wrapped editors. This combination, plus the bug in this issue, don't combine well.

(The dark grey type annotations in the screenshots are inferred and displayed with inline decorations, i.e. not part of the text in the actual file, and word wrap is on.)

@alexdima Do you have a sense of a reasonable approach to fix this? I'd like to start looking at the code soon, and a quick overview of what's going on from someone familiar would help greatly.

[trevyn]

@alexdima From the user perspective, this issue is a bug — soft wrapping is broken. I think this issue should be categorized as a bug, not a feature request.

[piersdeseilligny]

Unfortunately this seems like a pretty major architectural issue: From what I can tell (although I'm having a hard time wrap my head around the way it all works), the line breaks are computed before the decorations are processed, which is necessary in order to add the decorations in the first place.

For those who are more familiar with this codebase than I am, is this indeed what makes this bug difficult to fix? And would there be any realistic workaround?

[logicelf]

Unfortunately this seems like a pretty major architectural issue: From what I can tell (although I'm having a hard time wrap my head around the way it all works), the line breaks are computed before the decorations are processed, which is necessary in order to add the decorations in the first place.

For those who are more familiar with this codebase than I am, is this indeed what makes this bug difficult to fix? And would there be any realistic workaround?

Ah, that might explain why this has been an issue for so long. Damn it - this is making me twitch every day.

[trevyn]

Just introduced a new user to VS Code, immediately ran into this issue, and had to say “oh yeah, that’s a bug in VS Code.” Does anyone know who is the DRI for user experience for VS Code at Microsoft?

[rami3l]

@trevyn I think this issue needs more care. As a user of rust analyzer, I am really getting annoyed. I don't have access to a large monitor all the time, so I really need word wrapping when working on my laptop's screen, vertically split into two editors, however this bug ruins it all when I have a line of more than 2 inlay hints :(

[trevyn]

Unfortunately this seems like a pretty major architectural issue: From what I can tell (although I'm having a hard time wrap my head around the way it all works), the line breaks are computed before the decorations are processed, which is necessary in order to add the decorations in the first place.

For those who are more familiar with this codebase than I am, is this indeed what makes this bug difficult to fix? And would there be any realistic workaround?

Wait, why do decorations have to be applied after line break? From a layout perspective, decorations are just blocks inserted inline into the text flow, they don’t impact wrap points. (Or, errrrrr, don’t have to for a first pass at this problem.)