When editor text wrap is enabled, extensions should never cause horizontal scrolling.

[gwk]

• VSCode Version: Version 1.21.0-insider (1.21.0-insider) 9a4ba7d
• OS Version: 10.13.4 Beta (17E150g)

Steps to Reproduce:

1. Configure VSCode to wrap text (I believe this is the default).
2. Install gitlens extension.
3. Open a project that has a git history.
4. Place the cursor on a line that is almost the length of the editor window.

With the default settings, Gitlens draws text at the end of the current line showing git blame info.
This causes the line length to exceed that of the window, thereby enabling horizontal scrolling.
Note that horizontal scrolling is not possible, even with wrapping lines, until the first time gitlens takes this action and causes an overflow. The only recourse I see is to reload the editor window, but it's just a temporary fix until gitlens does it again.

I think this is a design problem with the core VSCode editor. I do not want the editor to scroll horizontally, ever, unless wrapping is disabled. That an extension can cause the core UI to switch into a fundamentally different (and annoying) mode seems to me a flaw in the editor itself. The alternative is to blame the extension; perhaps there is some way of configuring GitLens to prevent this but I have tried and haven't found it yet. To reiterate, it seems reasonable to ask that the editor not allow extensions to break the basic layout constraint that the editor does not scroll horizontally.

The reason this is so annoying is that once horizontal scroll is enabled, then when I scroll vertically with the trackpad I tend to shift the horizontal scroll slightly, thereby visually clipping the left side of the document by a character or two. Even after coping with this for months, I still get thrown off by it.

Does this issue occur when all extensions are disabled?: Not sure. Currently the repo depends on an extension, but it seems like something that the core should prevent.

[gwk]

Also filed with GitLens: gitkraken/vscode-gitlens#290

[eamodio]

Unfortunately I don't think there is anything GitLens (or any extension that uses an after decoration) could do to prevent this. I played with changing the DecorationRangeBehavior but I didn't see any change.

I feel like this changed somewhat recently -- where after decoration now affect scrolling. FWIW, I prefer that they affect scrolling, but they should honor the editor wrapping if they do.

Also related if an after decoration causes a line to grow and cause the scrollbars to appear, when the decoration is removed, the scrollbars don't go back to the previous state.

[alexdima]

Currently, inline decorations (such as CSS color boxes or git lens decorations) are implemented via CSS :before / :after selectors and they are unknown to the editor.

[eamodio]

As a hack, when the editor is in word-wrap mode, maybe the :after can be position: absolute to pull it out flow so it won't scroll?

[alexdima]

@eamodio That is a good thought, but I think that would not work for all possible types of :after decorations (that can occur in the middle of the text, and which should push the text to the right, and which should result in an horizontal scrollbar). It might only work for :after decorations that are at the end of a line.

[eamodio]

Ah, right. I forget you can have them anywhere :)

[alexdima]

Let's track in #32856