Implement word wrapping for non monospace fonts

[paul-go]

It's wrapping at the wrong place. I'm assuming the line measurement is happening based on character counts rather than the sum of the character widths? This doesn't work so well for us proportional font coders ;-)

[alexdima]

Indeed, we wrap based on the width of n and on the width of a double width character (think CJK). Then, the wrapping code only differentiates between latin and double width characters.

[mikemaccana]

Same here. Quick example:

[paul-go]

@alexandrudima Realistically speaking, is there any chance of this ever getting looked at? Or is the refactoring that this would incur just not worth the cost?

Shameless evangelism: Proportional font coding is amazing. Can't understand why more people don't do this. Code is far more readable. Can fit 2x the amount of code on the screen at once. Helps you catch typos easier. And makes my code look so beautiful :)

[zspitz]

@paul-go I've found that using a proportional font lets me focus on the entire keyword/identifier while reading. A monospace font tends to emphasize the individual letter, This is good for APL, but for any language which uses longer keywords/identifiers -- not so much.

[matsieftw]

I've specifically found that my horizontal scroll behavior is broken on .vue files. I have word wrap set (and lines are properly wrapping), but on my .vue files, horizontal scrolling is still there. This doesn't appear to be happening on my regular .js files, though.

[alexdima]

@matsieftw color decorators are not taken into account when computing wrapping points (#32856)

[matsieftw]

What does that even mean? My lines wrap fine, VSCode still makes the file super wide so it still has a horizontal scroll. As I asked in my original ticket. I’d like to be able to disable horizontal scrolling since word wrapping and limiting the number of columns does not appear to be an effective way to disable the horizontal scroll bar.

[alexdima]

@matsieftw The computation of the wrapping points (where to break a line) occurs in the view model. The view model is currently unaware of the color decorations (the rectangles with color that are inserted in the line); those color rectangles are inserted after the fact in the view, after the wrapping points have been computed. This is tracked in #32856:

[zspitz]

@alexandrudima

This is what I'm seeing when editing Markdown (outlined in red):

AFAICT this has nothing to do with color decorations.

[matsieftw]

My file doesn’t have any color decorators. I don’t understand why that’s relevant. I made a ticket because despite having proper word wrapping my files are still super wide and have horizontal scroll. I want to be able to disable the horizontal scroll. The fact that I can scroll entirely past all my text to long blank sections of my lines is annoying.

[alexdima]

@zspitz Yes, you are using a non-monospace font and this is a known issue tracked in this issue. Thank you for the screenshot, but really not needed at this point.

@matsieftw I've reopened your issue #59054. Let's continue investigating your precise unique problem there.

[rmorabia]

@alexandrudima Realistically speaking, is there any chance of this ever getting looked at? Or is the refactoring that this would incur just not worth the cost?

Echoing this here. Is this being worked on at all? Any information about where it is on the priority list?

[jabacchetta]

Not sure if these should be filed separately, but two other related issues that bug me in VSCode:

• The horizontal scroll bar appears when it's not necessary (i.e. editor.wordWrap is enabled, but that is not taken into account).
• When removing overflow, the horizontal scroll bar does not get removed until a different editor is focused.

[yspreen]

I don't think it's an issue with non-monospace fonts only. I use operator mono and usually wrapping works. But sometimes, when typing a line that is wrapped while typing, the wrapping breaks.

From that point on the horizontal scrollbar is always visible, and the last characters that are typed in a long line always mess up the scrolling.

you type normally, the line is completely visible and scrolled all the way to the left
-> you extend the current line until it should be wrapped
-> the last 1-2 characters go too far. The editor has to scroll to the right to show them
-> the word finally wraps
-> since the cursor is at the end of the word, it does not have to scroll all the way to the left
-> your editor remains scrolled 1-2 characters to the right.
-> The first 1-2 characters of the document are not visible anymore

This issue is really bothering me, I hope this gets seen

image of the broken scrollbar. Once it breaks you can really scroll way too far

Image where you can see the end result after the steps above. The first chars are hidden.

[qaqz111]

Comment from #70627.

@alexdima Yes you are right about the width of characters like U+2018, and that's the point. According to the Unicode® Standard Annex #11 these characters are East Asian Ambiguous, therefore require additional information not contained in the character code to further resolve their width.

But VSCode seems to treat them as simple Narrow characters and give them halfwidth characters' width regardless the font used and therefore the horizontal scrollbar appears in word wrap mode.

To reproduce this issue:

1. Use a chinese or japanese font as first value of Editor: Font Family in preference which give these Ambiguous character wide width(e.g. Simsun in a Simplified Chinese Windows)
2. Input some text in VSCode editor like ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890
3. Toggle Word Wrap in VSCode through command or Alt+Z
4. Copy one or all of these characters ‘’“” and paste to line begin repeatly, and you'll see the horizontal scrollbar appears
5. Press Alt+Z repeatly and pay attention to the horizontal scrollbar you can see the issue

The point is, these characters ‘’“” in most East Asia context (e.g. chinese) they are always wide width as fullwidth characters, but VSCode can not process them correctly.

This link provides the width info about the characters' EAST ASIAN WIDTH, and can be of some help.

[alexdima]

To try out, you can use "editor.wrappingAlgorithm": "dom", but be warned that it is orders of magnitude slower than the default one, "editor.wrappingAlgorithm": "monospace"