Toggle word wrap no longer works in 1.9

[GregCaldock]

Used to be able to toggle word wrap on and off with alt-z and changing "editor.wordWrap": to either true or false manually has no effect either.

It seems the only way to change the wrapping is to update the settings and change "editor.wrappingColumn" to -1 (for no wrap) and anything else for wrapping

• VSCode Version: Code 1.9.0 (27240e7, 2017-02-02T08:21:13.228Z)
• OS Version: Linux x64 4.4.0-59-generic
• Extensions:

Extension	Author	Version
jshint	dbaeumer	0.10.15
python	donjayamanne	0.5.6
php-intellisense	felixfbecker	0.0.12
phpcs	ikappas	0.7.0
seti-icons	qinjia	0.1.3

---

Steps to Reproduce:

1. press alt-z or change editor.wordWrap to true or false
2. only way to switch off wrapping is to set editor.wrappingColumn to -1

[alexdima]

Mastering line wrapping

There are two important settings in VS Code that control line wrapping.

• editor.wrappingColumn (300 by default)
• and editor.wordWrap (false by default)

It is important to understand the need for two distinct settings and how to tweak them to suit your use-case:

Examples (with explanations):

wordWrap	wrappingColumn	Explanation
false	300	Lines will wrap at 300
false	0	Lines will wrap at viewport_column
false	-1	Lines will never wrap.
true	300	Lines will wrap at min(viewport_column, 300)
true	0	Lines will wrap at viewport_column
true	-1	Lines will never wrap.

[tiago-plank]

Has this behavior changed with 1.9?

It used to be that I had editor.wrappingColumn at 120, and editor.action.toggleWordWrap would toggle between lines wrapping at 120 and lines not wrapping at all.

Is there no way to set up this use case now?

[alexdima]

What has changed in 1.9 is that toggling from the action will write to the user settings editor.wordWrap:true or editor.wordWrap:false.

Perhaps there are some workspace settings that override these values? (i.e. workspace settings override user settings)

[Bill-Stewart]

I think it is counterintuitive that any wrapping occurs when wordWrap is set to false. My opinion is that the behavior should be as follows:

wordWrap	wrappingColumn	Explanation
false	any value	Lines will never wrap
true	-1	Lines will wrap at min(viewport_column, wrappingColumn)
true	0	Lines will wrap at viewport_column
true	>= 1	Lines will wrap at specified column

[CaselIT]

@Bill-Stewart That was how it was working before.
The previous logic was better, but you can now put a very large value to wrappingColumn and have effectively the same behaviour.

Still I agree that it is counter-intuitive..

[alexdima]

@Bill-Stewart

The entry in your table for wordWrap: true and wrappingColumn: -1 suggests that lines will wrap at min(viewport_column, wrappingColumn) which is min(viewport_column, -1) which is -1 ?

[Bill-Stewart]

Sorry, meant this:

wordWrap	wrappingColumn	Explanation
false	any value	Lines will never wrap
true	<= 0	Lines will wrap at viewport_column
true	>= 1	Lines will wrap at specified column

[alexdima]

@Bill-Stewart You can express those 3 options with a single setting, wrappingColumn, there's no need to have 2 settings drive the 3 options you present:

wrappingColumn	explanation
< 0	lines will never wrap
0	lines will wrap at viewport column
> 0	lines will wrap at specified column

And in fact, that's what wrappingColumn does when wordWrap is false. Just look at the first 3 lines in my original table. So just do not use editor.wordWrap at all in your daily life or leave it to the default false.

wordWrap	wrappingColumn	Explanation
false	300	Lines will wrap at 300
false	0	Lines will wrap at viewport_column
false	-1	Lines will never wrap.
true	300	Lines will wrap at min(viewport_column, 300)
true	0	Lines will wrap at viewport_column
true	-1	Lines will never wrap.

---

Your proposal removes the min(viewport_column, wrappingColumn) row, effectively removing #1490 which can be implemented by removing the setting wordWrap altogether.

I'm not sure what we're debating here. There are 2 categories of users that care about wrapping:

Mild interest in wrapping

Only care about viewport wrapping => use editor.wordWrap, a simple boolean, changed also by the action in View menu. Simple, Easy, Efficient.

Expert, high interest in wrapping

Care about the precise conditions when wrapping occurs => now also use editor.wrappingColumn, and read and follow the table. More complicated, but that is the cognitive price to be paid by having more knobs.

[Bill-Stewart]

Hi Alex, thanks for the explanation. I guess I was just trying to point out that, at minimum, it seems quite counterintuitive to me there is any wrapping at all when wordWrap is set to false. Perhaps the option needs a better name than wordWrap - for example: wordWrapAtViewport.

[CaselIT]

@alexandrudima Why not change it to

wordWrap	wrappingColumn	Explanation
false	-1	Lines will never wrap.
true	-1	Lines will wrap at viewport_column

This way the use case of "usually wrap the lines, but when needed turn off the wrapping with the hotkey" is preserved. At the moment I'm setting wrappingColumn to something like 10000 to have this behaviour, since there is no option to allow it.

As an alternative revert to the 1.8 logic so that:

wordWrap	wrappingColumn	Explanation
false	0	Lines will never wrap
true	0	Lines will wrap at viewport_column

[alexdima]

Thanks for the additional ideas. Just as a notice, nothing has changed in the semantics of these two settings with 1.9.0. The only thing that has changed in 1.9.0 is that the action to toggle word wrap now writes editor.wordWrap to user settings.

@CaselIT So your proposal would be ?:

wordWrap	wrappingColumn	Today	After
false	300	Lines will wrap at 300	No change
false	0	Lines will wrap at viewport_column	No change
false	-1	Lines will never wrap.	No change
true	300	Lines will wrap at min(viewport_column, 300)	No change
true	0	Lines will wrap at viewport_column	No change
true	-1	Lines will never wrap.	Lines will wrap at viewport_column

[CaselIT]

Thanks for the additional ideas. Just as a notice, nothing has changed in the semantics of these two settings with 1.9.0. The only thing that has changed in 1.9.0 is that the action to toggle word wrap now writes editor.wordWrap to user settings.

I think that something has changed since I've had wrappingColumn set to 0 from vscode 0.x and up to version 1.8.1 I could toggle the word wrap on and off.

Regarding the table, yes that would be my proposal.
As an alternative, the equivalent (with the benefit that it wold work as it did before):

wordWrap	wrappingColumn	Today	After
false	300	Lines will wrap at 300	No change
false	0	Lines will wrap at viewport_column	Lines will never wrap.
false	-1	Lines will never wrap.	No change
true	300	Lines will wrap at min(viewport_column, 300)	No change
true	0	Lines will wrap at viewport_column	No change
true	-1	Lines will never wrap.	No change

[dbc60]

I'd like to suggest that the action to toggle word wrapping should toggle the user setting if and only if there is no workspace setting. That would avoid this unexpected behavior.

[tbfleming]

What about those of us who open a mix of files at the same time?

e.g.

• I don't want my source files to wrap to the window width
• I do want my .txt files to wrap to the window width

The old behavior worked great; I'd just hit ctrl-z on the text files I opened. Now I have to hit ctrl+z every time I tab between a text file and a source file.

[CaselIT]

@alexandrudima just to know since this issue is closed, is some work planned for this issue to implement the behavior you mentioned in #19842 (comment) ? Alternatively would a PR be accepted?
Thanks

[Bill-Stewart]

@tbfleming - I believe this is because the wordWrap setting now gets persisted to the config file - see comment from @alexandrudima earlier in this issue.

[tbfleming]

Maybe there should be an option to disable that persistence? Why was that change even made? Nothing else that I know of changes the settings file like that.

[Download]

I tried, but setting wrappingColumn to 32767 did not help either. My lines are now always wrapping... which is completely useless to me.

I was actually getting used to column editing features of VSCode, causing me to change from my tried and trusted Notepad++ to VSCode more and more often... Until this bug. I can no longer use those features because no matter what I do, all my lines wrap.

Is there a simple way to downgrade to < 1.9?

[Download]

Thanks for the additional ideas. Just as a notice, nothing has changed in the semantics of these two settings with 1.9.0.

Please do some more testing. Word wrap is horribly broken for my uses. I never even knew about the wrappingColumn setting... just using Toggle Word Wrap when needed / convenient. But I just came here because since 1.9.0 it's not working. It's stuck in wrapped mode. Now I can't use column editing features anymore and lost most of the benefits of VSCode... It's definitely not 'nothing has changed'!

[Bill-Stewart]

The change was that the wordWrap setting is now persisted to the settings.json file when you change it.

IMHO some settings should read a default from settings.json but not persist to settings.json when updated while editing.

[Download]

So toggling word-wrap on one editor window enables it for all? That sounds really weird to me.

[tbfleming]

@Download yes

[Download]

IMHO some settings should read a default from settings.json but not persist to settings.json when updated while editing.

Yes sounds a lot better.

[alexdima]

The Toggle Word Wrap action now persists to user settings because the rest of the View actions persist to user settings.

Toggle Word Wrap in 1.8.1

• It would change a setting "in memory" on the code editor instance.
• Using an "in memory" value meant that anytime the settings.json would be touched, the settings would be reloaded and the "in memory" value would be lost. This would happen rarely.
• This was the behaviour since more than a year
• In the meantime, we have (collectively, the entire team) made all the View actions persist to user settings. Plus there is a lot of new code being written every day where things are persisted to user settings (e.g. prompts where the choice is remembered as a user setting, etc).
• e.g. zooming in / zooming out now writes to user settings. this causes the settings.json file to be touched, and the settings to be reloaded and the "in memory" value to be lost. This made it that the "in memory" value would get lost a lot more often.

1.9.0

• Thanks to a lot of bugs where people were complaining that word wrapping "is lost", I was basically forced to persist it also inside the user settings.json, same as all the other view menu actions.

I am really sorry for the pain this change is causing, please simply review your workbench settings and remove editor.wrappingColumn and editor.wordWrap from your workbench settings. All in all, yes, the action is now simply typing something into settings.json on your behalf, kind of like a macro. It has no special "in memory" things anymore.

Tip: You can also use language specific settings to customize to your heart. e.g.:

"[plaintext]": { "editor.wordWrap": true }

[tiago-plank]

It still seems to me like the meaning of "editor.wrappingColumn": false is counter intuitive.

Moreover, I don't think my use case for Toggle Word Wrap prior to 1.9.0 is possible any longer, regardless of global of workbench settings. Namely, I would:

• Set "editor.wrappingColumn": 120
• Use Toggle Word Wrap to toggle between wrapping at 120 columns and not wrapping at all.

Setting editor.wrappingColumn to a specific value, and having a viewport_columnwider than that value results in Toggle Word Wrap doing essentially nothing.

[Download]

@alexandrudima
Sorry if we were (I was) a bit pushy on this subject... I have seen many cases of 'denial' so to speak. Thank you for acknowledging the issue.

Thanks to a lot of bugs where people were complaining that word wrapping "is lost", I was basically forced to persist it also inside the user settings.json

Ha! Conflicting requirements... Always fun!

I think the way to solve this would be to create an extra level in the settings hierarchy. In addition to defaults / global / user settings / settings per filetype, you should store settings per file. Once a file is opened and the word wrap toggle is used, you store the setting under the filepath as key:

{
  "filesettings": {
    "src/myfile.js": {
      "wordwrap": true
    }
  }
}

When a file is opened, you gather the value for wordwrap by going up the hierarchy:
file setting -> file type setting -> project setting -> global/default setting

if wordwrap is false, don't wrap.
if wordwrap is true, get the value for wrappingColumn by going up the hierarchy:
file setting -> file type setting -> project setting -> global/default setting
then apply wrapping according to min(viewport_column, wrappingColumn)

[Gobd]

@Download
Certainly needs something like that, I came here because "toggling wordwrap" did nothing which is very confusing. Now to toggle wordwrap I have to go to user settings and toggle editor.wrappingColumn between 0 and -1. Would be nice to have per file wrapping.

[alexdima]

I am convinced we have an usability problem here. I have extracted #21262 to address this option mess and I will implement the proposal there.

There is also #20675 where we should track the notion of a per-buffer dynamic (in memory or perhaps persisted) setting.

[CaselIT]

Thank you @alexandrudima !

[alexdima]

We have decided in today's standup that for 1.10 , we make Toggle Word Wrap "in memory" again ( #21291). i.e. it will not write to user settings, and it will apply only to the current editor instance.

It also means that the wrapping is highly transient. i.e. any touch of the settings.json will lead to it being lost. This is being tracked in #21487