Repository navigation
Formatter settings not updated after edit #691
Description
I edited a custom Eclipse formatter file so that brackets are on the same line for classes, methods, etc, and I have it added to my user settings json as:
"java.format.settings.url": "/Users/zeturk/Dropbox/MyEclipse.xml"
MyEclipse.xml file:
https://pastebin.com/raw/YvTtsMVW
but when I go back to a project and format the code, it is not updated to the settings specified (even if I reload or completely restart VSCode).
Any help is appreciated! (Sorry if this is an easy fix, pretty new to VSCode)
Environment
- Operating System: MacOS
Reacted by Arjun Surendra and Dave Landis
Activity
snjeza commentedon Oct 29, 2018
I can't reproduce the issue.
Could you check your workspace settings (<your_project>/.vscode/settings.json)?
snjeza commentedon Oct 29, 2018
Could you attach your log (the contents of the Output view)?
snjeza commentedon Oct 29, 2018
See #689 (comment)
dlandis commentedon Nov 23, 2020
I am also seeing this issue now.
When you set
"java.format.settings.url"to a local file, and then update the one of the settings in the xml file, the formatter doesn't pick that individual change up. Try changing one of settings in the xml file like:and then reformatting a java file. The line split won't change.
However, if you create a totally new xml file and then point the
"java.format.settings.url"to the new file, the newlineSplitwill be used when you reformat next time. Hope that helpsrobstryker commentedon Nov 2, 2026
The fix: commit 1400ad5d ("Link .settings directory to 'invisible project'", Apr 2021, #1579) restructured
fileChanged() to check the formatter/settings URL match before the resource == null early return, and separately
started linking such external config files into the invisible project so they're watchable. Current code
(StandardProjectsManager.java:207-246) checks formatterUrl/settingsUrl against the changed URI up front, and only
falls through to the resource-based build logic afterward — so an edit-in-place now correctly triggers
configureSettings() regardless of whether the file is inside the workspace.
So: real bug, root cause is the early-return-before-formatter-check ordering combined with getFileOrFolder failing on
non-workspace paths, and it was fixed (likely incidentally, as part of unrelated invisible-project work) in 2021 —
after the issue was filed but it looks like it was never explicitly closed/linked back to #691.
@MeherSru Can you test this and verify it's not replicatable any longer?
Primary repro (the original bug)
original reporter) — this is the key condition, since the bug only manifested for files not resolvable as an
IResource inside the workspace.
setting works at all).
brace position/indentation style. Save the file.
Secondary checks (cover both watcher paths and regressions)
worked even pre-fix, so it should still work and acts as a control.
content at the same path, and format again — this exercises registerWatchers() being re-invoked on CREATED/DELETED.
profile and confirm it's picked up, since FormatterManager.readSettingsFromStream is profile-aware.
code path handles both, so the same external-file edit test should be run there too.
running the same steps on Linux and Windows (path separators, case sensitivity, symlinks like ~/Dropbox) to make
sure the fix isn't platform-specific.
Thanks!