Introducing Swift for Visual Studio Code

sourcekitd is not the same thing as sourcekit-lsp never mind, i just tested the new plugin and it looks like it does use sourcekitd! great!

Thanks. I have used VSC for quite a while using thethe maintained Swift Development Environment.

I had to switch back to Xcode from time to time to manage documentation. I have made an attempt now to add this functionality to VSC. So if you want to give a try look at this new extensions which mimics the Add Documentation from Xcode.

This is my first extension, so it may have rough edges. Please let me know if you run into issues using this.

Swift Add Documentation

1 Like

This looks really cool.

There is an issue already for doing something similar in the swift extension as having to remember the structure of comment blocks while using vscode is a pain. I was looking at the vscode.CompletionItem system to implement this, to give a similar experience to the rest of VSCode.

For example when I type /** in javascript I get a basic javascript comment header /** */. If I press return it supplies a full function comment header with parameter names etc. The code for the javascript version looks like it uses the language server to get the parameter names which is an interesting idea.

If you are interested in contributing that'd be great.

As I wrote this was my first extension and supporting something like the language server was a bridge too far for me at this point. My goal was to have something working quickly. Since everything was new I cut some corners.

If you can give me a pointer to an example that is interacting with the swift language server I may look into it. Once I have it working we could migrate it to the main package and get rid of this package all together. In the mean time this works for me :slight_smile:

I'm not that far ahead of you :sweat_smile:. Interacting with the language server is a fairly complex affair. There is virtually zero documentation on how to do it via the vscode language apis. If I get the time I'll see if I can work out what is needed and add more details into the issue.

In the meantime we still have a solution

1 Like

My PR to microsoft/monaco-editor has been (almost) approved, if that helps any.

Thanks @0xTim for pulling me in, and sorry for the delay.

We’re working towards adding such feature officially in Swift, and the prototype documentation (my GSoC write-ups) is live in GitHub - stevapple/gsoc-2021-writeups: Write-ups of GSoC 2021 project "SwiftPM support for Swift scripts".

Currently the prototype has little IDE support, which is the main direction I’m evolving towards. It should be officially pitched as SE proposal once it has gain better frontend integration. I’ve noted the request and will see if we can provide it as an experimental feature of the plugin after it is available for testing.

Personally I think it’s unwise to add any third-party integration into this plugin. A separate one should be a better choice.

swift-sh is easy to detect and it would be cool if it would be supported. It is the de-facto standard for doing that thing today.

Would be cool if Swift would just make it first party instead of the usual NIH. But presumably shouldn't be hard to just support both.

Either way, someone has to do the work :slight_smile: And just supporting regular single-file scripts would be a cool first step.

By the way, for those waiting for test support to come to this plugin, there's this cool extension you can use in the mean time. I'm mentioning it because it may be of interest to those using VSCode, and because it may also help the developers to check out how this plugin does it; apparently it uses the "Test Explorer UI" plugin (which predates VSCode's official API), but migration to the official API is apparently straightforward.

2 Likes

Hi Adam,

I looked at the /** functionality and it turns out that this is part of the language configuration and this is supplied by the auto closing pairs mechanism. So similar to when you type { you also get `}'.

I can use this to for example use tab instead, so //<tab> would trigger the documentation template and when used inside a block would open up a new documentation line. Any thoughts?

Tab may be a wrong choice. It prevents from entering normal tabs. I guess that is why they used shift-enter as trigger command.

I had a quick look and a completionItemProvider that returns a snippet seems to be the solution. I setup a basic completion item which was triggered on pressing return. It would then check the line started with ///. If the line below included a function definition it would return a snippet including all the function params, if not it just added /// to the start of the line.

I quickly gave up on writing regular expressions to recognise functions as it got very complex very quickly. I won’t be near my computer until late tomorrow, I’ll commit my branch then if you want to have a look.

Yes, please do. The logic to recognize the line below is already in my package so I could simply extend it based on your code.

The SourceKit-LSP repository is now also officially suggesting to use the SSWG extension to use SourceKit-LSP in VSCode and has removed its own VSCode extension. Use the new VSCode Extension by 0xTim · Pull Request #441 · apple/sourcekit-lsp · GitHub

13 Likes

They just introduced "github.dev" which runs VSCode in the browser. This will be a game-changer for modifying repositories with the online IDE. I authored (and continue to maintain) Swift-Colab entirely using the web IDE, and this is greatly enhancing my workflow within minutes of trying it out. Any chance the Swift VSCode plugin can apply here to enhance or modify syntax coloring? I have never used Swift in VSCode until just now.

This should also make maintaining S4TF - a massive repository - much easier. I can now have closer-to-instantaneous feedback while running the repo on Linux. Previously, I could only have the fast feedback loop on macOS + Xcode.

1 Like

The extension doesn't wok in GitHub.dev or VSCode for the web because the sandbox it runs in doesn't allow the compiler to run (it's the same with any other compiled language like Rust or Go).

You can however use GitHub Codespaces which provides a similar thing using a slightly different environment

2 Likes

the async and await contextual keywords don’t receive syntax highlighting, apparently because the semantic highlighter classifies them as identifiers, and as far as i can tell, it is not possible to override a semantic highlight with a textmate highlight (which correctly detects it as a keyword.)

is there a fix?

Hmmm, I'm not getting that.

What version of vscode are you running? The highlighting is done VS Code. This is the code in here https://github.com/microsoft/vscode/blob/main/extensions/swift/syntaxes/swift.tmLanguage.json

By the way there is a section for vscode-swift in the related projects section of the forums VSCode Swift extension - Swift Forums. We shouldn't need to keep extending this thread.

the highlighting is not done by VSCode, it is done by sourcekitd. this is the issue i was alluding to earlier in this thread.

the reason you are seeing a colored await is likely because you have the syntax highlighting turned off, in your settings.json, or whatever VSCode theme you are using. because the highlighter is disabled, the editor attempts to apply the heuristics in swift.tmLanguage.json instead, which knows how to highlight await but is less accurate elsewhere.

i've observed a similar problem with #if, #else and friends, but because the VSCode swift extension doesn’t attempt to label them (whereas it labels await as an identifier), it is possible to provide a fallback for those in a way that is not possible for await and async, and probably override and the other contextual keywords as well.

(note: i don’t know why the preprocessor macros don’t get highlights, these labels exist in sourcekitd, and Atomic Blonde was always able to access them, so my guess is the VSCode extension is just discarding them.)

Moved this conversation here VS Code Semantic highlighting does not highlight async/await keywords