Format Document working, editor.formatOnSave=true broken

[gurgeous]

• VSCode Version: 1.19
• OS Version: Mac OS 10.12.6

I am having some trouble with editor.formatOnSave=true when using the Ruby extension. It isn't formatting on save. This is strange, because a manual Format Document works fine. How is that possible?

I assumed this was user error or an extension bug. So I modified the extension locally and added some debug output to this file:

https://github.com/rubyide/vscode-ruby/blob/master/src/format/rubyFormat.ts

I verified that the correct edits were being returned from provideDocumentFormattingEdits. This makes sense since a manual Format Document works fine. What am I missing? Could this be a vscode bug? Not sure how to debug further.

[bumbapartha]

This is happening for my TypeScript code as well. While saving, formatting is not working. Formatting is working if I do it separately. But my HTML files are getting formatted at the time of saving.

Here is my User Settings.

{
    "html.format.wrapLineLength": 80,
    "html.format.wrapAttributes": "force-aligned",
    "tslint.autoFixOnSave": true,
    "window.zoomLevel": 0,
    "editor.renderControlCharacters": true,
    "clang-format.executable": "C:/Users/MyUserId/AppData/Roaming/npm/clang-format",
    "editor.formatOnSave": true
}

[MikhailArkhipov]

This appears to happen when formatting takes longer than expected. I can repro this in Python as well. Python extension runs formatters in Python process and in a large file formatting may take 2-3-4 seconds. Format Document appears to be executing synchronously and succeeds which formatting on save appears to abandon formatting after a second or so. I.e. same file - when file is small, formatting on save works, but when content grows format on save stops working. Format Document always works.

[MikhailArkhipov]

https://github.com/Microsoft/vscode/blob/4fde7a37737b5ff2735568116f8ffa59084da509/src/vs/workbench/api/electron-browser/mainThreadSaveParticipant.ts

perhaps?

return new Promise<ISingleEditOperation[]>((resolve, reject) => {
			setTimeout(reject, 750);

[MikhailArkhipov]

Rather than setting hard budget, perhaps some sort of progress reporting would help

[MartinKavik]

@MikhailArkhipov Yeah, I've come to the same conclusion independently of this issue during debugging formatting in Elm extension (associated issue).

I think both time constants should be at least configurable from settings. Some progress reporting / throwing errors on timeouts to dev console will be nice.

• 1st constant (it causes this issue): https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/api/electron-browser/mainThreadSaveParticipant.ts#L201
• 2nd constant: https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/api/electron-browser/mainThreadSaveParticipant.ts#L269

I've confirmed this problem with 750ms limit when I've built VSC from source with that constant set to some bigger values (master branch from yesterday, Windows 10).

@rebornix I can try to create a PR if you or somebody else could suggest some correct way how to solve it or I'll try to investigate it deeper and come with some solution (I saw VSC's source for the first time yesterday ). Thanks!

[buyology]

Seeing the same thing with the vscode-go plugin which recently switched over to this logic with that hard limit. This totally must be configurable.

[buyology]

Sent a patch to make this configurable: #43702