Change:
const versionNow = model.getVersionId(); const { tabSize, insertSpaces } = model.getOptions(); <ins> const timeout = this._configurationService.getValue('editor.formatOnSaveTimeout', { overrideIdentifier: model.getLanguageIdentifier().language, resource: editorModel.getResource() }); </ins> return new Promise<ISingleEditOperation[]>((resolve, reject) => { <del> setTimeout(reject, 750); </del> <ins> setTimeout(reject, timeout); </ins> getDocumentFormattingEdits(model, { tabSize, insertSpaces }) .then(edits => this._editorWorkerService.computeMoreMinimalEdits(model.uri, edits)) .then(resolve, err => {

Discussion:
VSCode Version: 1.19 OS Version: Mac OS 10.12.6 I am having some trouble with when using the Ruby extension. It isn't formatting on save. This is strange, because a manual works fine. How is that possible? I assumed this was user error or an extension bug. So I modified the extension locally and some debug output to this file: I verified that the correct edits were being returned from . This makes sense since a manual works fine. What am I missing? Could this be a vscode bug? Not sure how to debug further.
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.
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.
perhaps?
Rather than setting hard budget, perhaps some sort of progress reporting would help
Yeah, I've come to the same conclusion independently of this issue during debugging formatting in Elm extension (associated ). 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): 2nd constant: 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). 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!
Seeing the same thing with the plugin which recently switched over to this logic with that hard limit. This totally must be configurable.

Sent a patch to make this configurable:
Also related
I think this is exacerbated by the opaqueness of the "format on save" feature. As a new user of vscode it's challenging to figure out what's happening: Did my document reformat? (this isn't always obvious) Did I configure vscode? Did I configure the extension? Did I configure the external formatting tool? Is my PATH correct? For formatters like prettier many of these questions don't apply, but I think it's an issue for other extensions. It would be worth adding some UX here to help the user understand what's happening.
The problem for making this configurable is that it might not be clear that saving is blocked. You'd be surprised how often someone forgets that he/she made a settings change that affects your workflow. There should already be a progress UI that shows a message like "Running Save Participants..."
Format on save is aborted in 750ms. There is no UI/message for either progress or for when formatting gets aborted for exceeding 750ms
Well, the message is delayed by 150ms (and showing for at least 150ms). The message is shown any participant which run sequentially - that still makes 750ms for format on save and 1750 for onWillSave. That should make 2500ms in total (given a slow formatter and a slow will-save-handler)
Now that you've pointed it out, I see a brief flash of when I hit Save. Might need some more consideration: I never noticed it before. It's a long way from my cursor. In fact, I've usually started typing again so I have no reason to move my eyeball around the screen. It's not on screen for very long (750ms?) The message is inscrutable
IMO any hard time limit is a problem. On large Python files formatting can take 3-4 seconds. command is not limited by time while saving is. This is at least inconsistent. has cancellation token. When saving file VSC could display progress or at least status bar message with and cancel the token if user decides so. Python extension worked around this (for now) by detecting if document actually changed on save and if it was not, forcibly reformatting and then saving.

This may not work if user decides to close dirty file and then clicks 'Yes' to the save prompt.
Can't imagine a situation where one would sit and monitor the -process and manually opt in to cancel it. That's just too much operational overhead. (If it's for debugging fatal errors in the extensions and the tools they call out to there already is the developer tool debug-route.) In at least, the pattern is that you hit save and expect and to run all the time — sometimes in very quick succession for every little change you make — and you quickly get used to the fact that it takes some extra time from time to time when you a) work on large projects and b) your computer is hung up doing other stuff. Also, a simple but great cue for understanding the progress of the formatting is the fact that your code is not yet correctly formatted, and you are quite OK with just waiting a bit longer or retrying by continuing working and hitting save again.
Looks like it is hard to discover and users are still confused. What's wrong with adding progress indicator with cancellation?