Feature "Toggle Word Wrap" broken in version 1.9.0

[c3er]

Since the update to version 1.9.0 it is not possible to switch on word wrapping. Both the key combination Alt+Z and the menu item don't show any reaction.

---

• VSCode Version: Code 1.9.0 (27240e7, 2017-02-02T08:31:00.827Z)
• OS Version: Windows_NT ia32 10.0.14393
• Extensions:

Extension	Author	Version
python	donjayamanne	0.5.8
cpptools	ms-vscode	0.10.0
csharp	ms-vscode	1.6.2
java	redhat	0.0.9

[jimmyko]

I had the same issue.

---

• VSCode Version: Code 1.9.0 (27240e7, 2017-02-02T08:23:30.856Z)
• OS Version: Darwin x64 15.6.0
• Extensions:

Extension	Author	Version
mithril-emmet	FallenMax	0.6.1
beautify	HookyQR	0.7.3
crane	HvyIndustries	0.2.2
format-indent	Kasik96	1.3.0
format-php	Kasik96	1.1.2
code-settings-sync	Shan	2.4.3
indenticator	SirTori	0.2.1
alignment	annsk	0.3.0
vscode-color	anseki	0.2.3
githistory	donjayamanne	0.1.5
python	donjayamanne	0.5.8
vscode-babel-coloring	dzannotti	0.0.4
vscode-npm-script	eg2	0.1.8
json-tools	eriklynd	1.0.2
php-debug	felixfbecker	1.10.0
php-intellisense	felixfbecker	1.1.1
code-runner	formulahendry	0.6.9
composer	ikappas	0.5.0
phpcs	ikappas	0.7.0
drupal-7-snippets	juniormucciolo	0.0.7
vscode-JS-CSS-HTML-formatter	lonefy	0.2.2
ftp-sync	lukasz-wronski	0.3.2
phpcsfixer	makao	0.0.1
VS-code-vagrantfile	marcostazi	0.0.4
vscode-scss	mrmlnc	0.6.1
debugger-for-chrome	msjsdiag	2.5.2
vscode-icons	robertohuertasm	7.2.0
sass-indented	robinbentley	1.3.0
annotator	ryu1kn	0.10.1
Spell	seanmcbreen	0.9.1
standard	shinnn	0.2.3
stylelint	shinnn	0.21.0
guides	spywhere	0.6.1
gitblame	waderyan	1.3.0
Material-theme	zhuangtongfa	1.0.3

[scrawfor]

Broken for me as well. If I toggle word wrap, I do see a difference, but the text still wraps. Specifically I get 3 lines instead of 4.

[rogerpence]

Broken in 1.91 as well.

[Tyriar]

I can't repro on Ubuntu 16.10 in latest insiders.

[geforcesong]

yes, broken on my mac.
vscode version is 1.9.1

[TapestryOfAges]

My issue falls under the subject heading but might be different from what others here are describing.
Ever since the 1.9.0 upgrade, attempting to toggle any of the three "toggle" commands (Word wrap, Render white space, Control characters) brings up the same error: "Unable to write settings. Please open User Settings to correct error/warnings in the file and try again." The settings.json file is unchanged from the version that worked fine in the previous version of VSC. If settings.json is deleted, the error goes away and Alt-Z once again toggles word wrap, however making a new settings.json, even with minimal changes, recreates this problem.
The problem persists through a uninstall and reinstall of VSC.
I see this problem on two different up-to-date Windows 7 machines. I am currently running VSC 1.9.1 with no extensions.

[jshall]

This error occurs for me on 1.9.1 (Windows) even when I launch with --disable-extensions.

I've noticed that the alt+z keybinding successfully updates editor.wordWrap in settings.json once, until I save the file manually then it can update the setting once more. Even then, whether I change editor.wordWrap manually or with the keybinding the editor always behaves as if it were set to false.

[pborenstein]

Take a look at #19842 especially the table in this comment.

I don't agree with the implementation, but it seems the feature is working as intended.

[TapestryOfAges]

If it wants to write editor.wordwrap to the user settings instead of doing whatever it used to do, maybe that's fine- it seems to work as I expect when I don't have a settings.json. So I guess my problem is not directly related to Word Wrap and is instead that if I have manually edited settings.json at all VSC fails in its attempt to write to the user settings and the attempt to change the word wrap fails out with an error that gives no hint as to how to solve the problem ("Unable to write settings. Please open User Settings to correct error/warnings in the file and try again"). It is possible that I should look for this as a separate bug or file one.

[c3er]

@pborenstein

Thanks for the explanation. I have set editor.wrappingColumn to 10000 now to restore the the behavior to that I'm used to. I'd like if the behavior suggested in this comment would be implemented.

But for me this issue is resolved.

@TapestryOfAges I have edited my user settings too but encountered no problems and could actually watch the value changing. editor.wordWrap is appended as last item to the JSON

[gulshan]

Had same issue. Removed "editor.wrappingColumn": 0 from my user settings and it is now working as intended for me.

[Download]

If your lines are longer than 300, they will still wrap even if you toggle word wrapping off... It is not resolved for me. Only generic resolution I've found is setting wrappingColumn to 32767 or some other huge value... making the setting pointless, but restoring Alt+Z to toggle word wrap.

[gulshan]

The explanation is at the end of this comment- #19842 (comment) -

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.

And my suggestion will be to not use both settings simultaneously. That use-case is rare- wrapping at min(viewport_column, wrappingColumn). Rather use either of them according to your intention.

[Download]

The point is that all of the sudden the option Toggle Word Wrap stopped working. Only here do I find out that there is a relation with wrappingColumn. But I just tried in a fresh project and there wrapping does work. But I did not have set the wrappingColumn setting in the other project so I don't really know what is up. Just that this all started around 1.9 and that I now see here a lot of bugs reported on it all closed.

What is the option Toggle Word Wrap supposed to do? Because it seems this option (in View menu) toggles the boolean flag right? So after setting wrappingColumn to some positive value, people should no longer use this option right?

[Bill-Stewart]

According to #19842 (comment) - the change in 1.9 is that toggling wordWrap now updates settings.json for some reason (I believe this is a substantial contributor to the confusion). My proposal instead is to introduce a concept of "dynamic" settings - see #20675.

In any case -- my opinion is that the behavior should be something like the following:

wordWrap	wrappingColumn	Effect
false	any value	no wrapping at all
true	<= 0	wrap at viewport
true	> 0	wrap at specified column

If vscode adopts the behavior in this table, the defaults would be editor.wordWrap: true and editor.wrappingColumn: 300.

I find it non-intuitive and confusing that when wordWrap is false there is sometimes wrapping, and when wordWrap is true there is sometimes not wrapping.

[c3er]

Does the setting "wrappingColumn" make sense at all? If the displayed text would be transformed actually (meaning line breaks are inserted at the specified column), it would make much sense and a "wrappingColumn" of 80 could be common. But I am not interested in just wrapping at some place that is not the viewport border. For me the text should break at the view port or not at all.

I wonder which use case or habit makes it necassery to specify a wrapping column that is not the viewport border.

[rogerpence]

I think Bill Stewart's comment makes a lot of sense. While I could live with c3er's ideas that "wrappingColumn" might be able to be deprecated, I like to use "wrappingColumn" to ensure that code wraps at an arbitrary right margin for publishing purposes. That said, if removing "wrappingColumn" made things easier to use wrapping with documents (ie, markdown instead of code) I could live with it.

[c3er]

@rogerpence Is it possible to save a document with a set "wrappingColumn"? That would answer my question above. If not, I wonder how this setting helps you publish.

[Bill-Stewart]

@c3er - the use case for wrappingColumn being less than viewport width is when you have a very wide editing window and you want wrapping at less than the entire width without changing the width of the window. (This is handy for example when working with HTML, markdown, etc.).

Aside: We need to be careful about distinguishing between visual line wrapping and actually inserting newlines into the editing buffer. The wrappingColumn and wordWrap settings affect only the visual display of lines in the editor and do not insert newlines.

[c3er]

@Bill-Stewart This is a valid use case and the discussion can go on ;) I still prefer the suggested canges in this comment. But I think any behavioral change should be treated very crtical.

[Bill-Stewart]

Yes - because now wordWrap persists to settings.json (I don't like this change but that's a separate issue), I would recommend leaving it set to false and simply modify wrappingColumn as needed instead. I wrote and published an extension to help with this:

https://marketplace.visualstudio.com/items?itemName=BillStewart.set-wrapping-column

[jackweinbender]

Ok. I'm starting to understand this. Yet, why---given that wordWrap was toggled in both cases---would the two files display differently? Apologies if I'm being dense.

[Bill-Stewart]

See #19842 (comment) for what the settings currently do and how they currently work.

[c3er]

@Bill-Stewart But just pressing Alt+Z is so easy and fast ;) If "wordWrap" would be replaced with your extension I would be fine too. But I guess we can agree that the current behavior is very unintuitive.

[c3er]

@jackweinbender I think it is the best if you open a new issue and append both the workspace settings file (if existing) and your user settings file.

[Bill-Stewart]

@c3er - you can still use the toggle if you want. Just be aware that it now changes your settings.json file (workspace if you have it, or global otherwise).

@jackweinbender - this isn't the right place for Q&A - ask here: http://stackoverflow.com/questions/tagged/vscode

[Download]

I still prefer the suggested canges in this comment.

points to comment describing how lines will wrap with wordwrap being set to false

this isn't the right place for Q&A

about a question about the behavior of wordwrap / wrappingColumn

Guys I've been reading some of the issues around this topic and it seems you are (a bit at least) in denial. The way it currently works is perceived by users as a bug. There are 2 reasons for that:

1. Settings which should override other settings (wordwrap:false) don't
2. Settings which should act per file, don't.

If I toggle word wrap for one file, it does not mean I want it toggled for every file. Au contraire! The primary reason for using toggle word wrap is to tempoarily / just for this file, deviate from the (default) settings. Meaning those settings are usually correct, just not for this file. By persisting that change as if it was intended for all files it really breaks the primary use case. The fact that wrappingColumn overrides wordwrap makes this even worse; in another comment the advice was to just use only one... However that means that if you specify wrapping column, the toggle menu option and shortcut become almost completely useless.

Solutions:

1. Make wordwrap override wrappingColumn
2. Either persist wordwrap per file or don't persist it at all when people use the toggle.

[Bill-Stewart]

Yes I basically agree: Some settings should only affect the current buffer and not persist to settings.json. This is why I created the feature request in #20675.

[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. IMHO this will reduce a lot of the friction with understanding or working with these wrapping-related settings.

There remains the problem of what Toggle Word Wrap should do. After #21262, it will write wordWrap: "on" | "off" to user settings. There remains the case the workspace settings contain an override for wordWrap which might cause the action to appear as a no-op. Let's track that in #21291.

Furthermore, there is also #20675 where we should track the notion of a per-buffer dynamic (in memory or perhaps persisted) setting and consider that Toggle Word Wrap should use it.

[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

[jshall]

Thank you. I think the new settings in 1.10 are more intuitive and much less confusing.