Extension|Author (truncated)|Version
---|---|---
vscode-styled-jsx|bla|0.2.2
simple-react-snippets|bur|1.1.1
arm|dan|0.1.2
vscode-eslint|dba|1.4.4
prettier-vscode|esb|1.1.2
sublime-babel-vscode|jos|0.2.9
Go|luk|0.6.73
python|ms-|0.9.1
material-icon-theme|PKi|3.2.1
python|tht|0.2.3
tiger-vscode|yun|0.0.1
JavaScriptSnippets|xab|1.5.0
(1 theme extensions excluded)
Steps to Reproduce:
"files.autoSave": "afterDelay"
Reproduces without extensions: Yes
Similar to #39051. Currently "files.autoSave" is not a supported language specific setting
I was just going to open the same issue. In my case, I'm finding it hard to configure VSCode for both JavaScript and Go development. For Go, files.autoSave is nice. For JavaScript, files.autoSave wreaks havoc with HMR or other bundle on change tools.
Can anyone provide guidance on how someone might fix this? Is there a commit or merge request that implements something similar that could be used as a starting point?
I see where overridable: true could be added to the files.autoSave (and autoSaveDelay) configuration: https://github.com/Microsoft/vscode/blob/7e7961895c6c940365bfc4bbf2287a8b8c851195/src/vs/workbench/contrib/files/browser/files.contribution.ts#L282-L293
Then it looks like overrides would need to be provided when getting the configuration: https://github.com/Microsoft/vscode/blob/7e7961895c6c940365bfc4bbf2287a8b8c851195/src/vs/workbench/services/textfile/common/textFileService.ts#L96
Maybe this override would look like
{overrideIdentifier: model.getLanguageIdentifier().language, resource}
But I'm uncertain what model and resource would be in this context. I also have no idea how this would impact other configuration and am uncertain how folder overrides are handled. And it looks like there are a few other places where the files.autoSave configuration is accessed that would need updating.
Any suggestions from vscode contributors on whether this is the right direction? I imagine there are complications, but would be happy to get something started unless this is something that is not easily achievable with the way this configuration is handled.
@tschaub I came to the same conclusion as you. Setting overridable: true where you suggested did indeed remove the "Unknown editor configuration setting" error in the settings.json file. But I couldn't figure out how to actually apply the settings.
I was testing this with a workspace, so that might be yet another variable here. I really want to have control over what files are auto saved. I have a workspace that has 2 project folders, one for api and one for front end. I suspect that many others do as well, this would be a great enhancement to Code.
Any guidance or insights you can offer us @bpasero?
It can be usefull for some sort of virtual FileSystemProviders when writeFile operation is very expensive.
Adding a reference to #82101 (allowing files.eol to be set per-language) in case there are things to crib from in that change.
This problem also bothers me. Expect to be resolved.
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
Missing Feature autosave just for current open directory file.
vote vote vote!
Yeah, I feel this feature could be really helpful to me!
Autosaving for source code is nice, but when editing latex file with 'compile upon save', frequent save can keep on invoking the compiler and let error messages flood in... I deal with it by toggling autosave or set up a workspace config, neither of which is really neat. So I would really love it if we can config autosave for different file types!
Bump.
Really need autosave for python (as of now), but for nothing else. It's annoying to keep toggling that setting.
Such improvements may be waited for years. Probably some custom extension is needed.
We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding and happy coding!
This feature would be great!
Most helpful comment
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!