Skip to content

Handle "textDocument/rangeFormatting" and "textDocument/onTypeFormatting" #1805

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MahdiBM opened this issue Nov 5, 2024 · 11 comments · Fixed by #1806 or #1815
Open

Handle "textDocument/rangeFormatting" and "textDocument/onTypeFormatting" #1805

MahdiBM opened this issue Nov 5, 2024 · 11 comments · Fixed by #1806 or #1815
Labels
enhancement New feature or request

Comments

@MahdiBM
Copy link
Contributor

MahdiBM commented Nov 5, 2024

Description

Now that swift-format has some support for range formatting, sourcekit-lsp can implement handling these requests as well.

This will elevate the VSCode formatting experience since the VSCode extension is calling through to sourcekit-lsp for formatting.

sourcekit-lsp seems to already have some support for these. Just the logic isn't implemented.
For example there are some existing DocumentRangeFormattingRequest and DocumentOnTypeFormattingRequest types.

@ahoppen
Copy link
Member

ahoppen commented Nov 5, 2024

Synced to Apple’s issue tracker as rdar://139287738

@MahdiBM
Copy link
Contributor Author

MahdiBM commented Nov 7, 2024

@ahoppen How would you like OnTypeFormatting to be implemented?

I quite like the Xcode formatting behavior, so not sure if any of your colleagues working on Xcode can provide some tips about this.
Also not sure that swift-format will have the ability to do those formatting anyway, even if we knew Xcode's algorithm.

What I did for the vknabel formatter extensions was to perform a format of the whole file after hitting "return" on non-empty lines. But that formatted the whole file, not just some certain lines (this was before the selection-formatting PR being merged into swift-format).

I guess we could start with that "perform a format of the whole file after hitting "return" on non-empty lines" although I'd like to leverage the selection-formatting capabilities.

@ahoppen
Copy link
Member

ahoppen commented Nov 7, 2024

What do you think of running swift-format on the line that we receive the textDocument/onTypeFormatting request for if ch is a newline? I am a little doubtful how well this will work though because swift-format can’t format if you have syntax errors and I assume there will likely be syntax errors during typing.

Anyway, I think we would need to get a feel for this, so I’d implement it behind an experimental feature and then use it for a while to see how it feels and if we have improvement ideas.

@MahdiBM
Copy link
Contributor Author

MahdiBM commented Dec 13, 2024

@ahoppen why the reopen? Curious 🙂

@ahoppen
Copy link
Member

ahoppen commented Dec 13, 2024

Because it’s gated behind the experimental feature and thus not generally available.

@MahdiBM
Copy link
Contributor Author

MahdiBM commented Jan 17, 2025

@ahoppen friendly ping: I don't think textDocument/onTypeFormatting has made it to the 6.1 toolchains yet. I would have loved to try it out.

@MahdiBM
Copy link
Contributor Author

MahdiBM commented Apr 26, 2025

@ahoppen any updates on this? 🙂

@ahoppen
Copy link
Member

ahoppen commented Apr 28, 2025

On-type formatting should be available behind the experimental features. Is it not?

@MahdiBM
Copy link
Contributor Author

MahdiBM commented Apr 28, 2025

Not even on 6.2 nightlies. Does not appear to make any difference to turn it on or not (using config file).

@MahdiBM
Copy link
Contributor Author

MahdiBM commented Apr 28, 2025

There are no logs related to on-type-formatting so it doesn't even get triggered.
Testing on a dev container using 6.2 nightly images (not the latest image though, but a recent one).

@MahdiBM
Copy link
Contributor Author

MahdiBM commented Apr 28, 2025

Could this be related to #2124 ?

Another thing; Checking for experimental flags in the logs shows mixed results:

$ tail -F -n 10000 ~/.sourcekit-lsp/logs/* | grep experimentalFeatures -A 10 -B 10 -n
34116-  "backgroundIndexing" : 1,
34117-  "backgroundPreparationMode" : "<private fb9cf75606b4070d>",
34118-  "clangdOptions" : [
34119-
34120-  ],
34121-  "compilationDatabase" : {
34122-    "searchPaths" : [
34123-
34124-    ]
34125-  },
34126:  "experimentalFeatures" : [
34127-
34128-  ],
34129-  "fallbackBuildSystem" : {
34130-    "cCompilerFlags" : [
34131-
34132-    ],
34133-    "cxxCompilerFlags" : [
34134-
34135-    ],
34136-    "swiftCompilerFlags" : [
--
34172-  "backgroundIndexing" : 1,
34173-  "backgroundPreparationMode" : "<private fb9cf75606b4070d>",
34174-  "clangdOptions" : [
34175-
34176-  ],
34177-  "compilationDatabase" : {
34178-    "searchPaths" : [
34179-
34180-    ]
34181-  },
34182:  "experimentalFeatures" : [
34183-    "<private cebebca138850fa6>",
34184-    "<private 66698aa4335cd79b>"
34185-  ],
34186-  "fallbackBuildSystem" : {
34187-    "cCompilerFlags" : [
34188-
34189-    ],
34190-    "cxxCompilerFlags" : [
34191-
34192-    ],

The one above is with logging.privacyLevel set to private in the config, and it shows no experimental features (EDIT: or at least that's what I think based on what I did).
The one below is with the default logging settings and shows 2 experimental features.
This is with me having set experimentalFeatures to ["on-type-formatting", "structured-logs"].

EDIT: interesting that backgroundPreparationMode is always showing up as "<private>" ... maybe my config stuff are not taking effect at all?! They are at project/.sourcekit-lsp/config.json and I'm using the official VSCode extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
2 participants