Skip to content
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

Update Editors/README.md #1184

Merged
merged 8 commits into from
May 15, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
53 changes: 1 addition & 52 deletions Editors/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,58 +22,7 @@ The [Swift for Visual Studio Code extension](https://marketplace.visualstudio.co

## Sublime Text

Before using SourceKit-LSP with Sublime Text, you will need to install the LSP package from Package Control. To configure SourceKit-LSP, open the LSP package's settings. The following snippet should be enough to get started with Swift.

You will need the path to the `sourcekit-lsp` executable for the "command" section.

```json
{
"clients":
{
"SourceKit-LSP":
{
"enabled": true,
"command": [
"<sourcekit-lsp command>"
],
"env": {
// To override the toolchain, uncomment the following:
// "SOURCEKIT_TOOLCHAIN_PATH": "<path to toolchain>",
},
"languages": [
{
"scopes": ["source.swift"],
"syntaxes": [
"Packages/Swift/Syntaxes/Swift.tmLanguage",
"Packages/Decent Swift Syntax/Swift.sublime-syntax",
],
ahoppen marked this conversation as resolved.
Show resolved Hide resolved
"languageId": "swift"
},
{
"scopes": ["source.c"],
"syntaxes": ["Packages/C++/C.sublime-syntax"],
"languageId": "c"
},
{
"scopes": ["source.c++"],
"syntaxes": ["Packages/C++/C++.sublime-syntax"],
"languageId": "cpp"
},
{
"scopes": ["source.objc"],
"syntaxes": ["Packages/Objective-C/Objective-C.sublime-syntax"],
"languageId": "objective-c"
},
{
"scopes": ["source.objc++"],
"syntaxes": ["Packages/Objective-C/Objective-C++.sublime-syntax"],
"languageId": "objective-cpp"
},
]
}
}
}
```
Before using SourceKit-LSP with Sublime Text, you will need to install the [LSP](https://packagecontrol.io/packages/LSP), [LSP-SourceKit](https://github.com/sublimelsp/LSP-SourceKit) and [Swift-Next](https://github.com/Swift-Next/Swift-Next) packages from Package Control. Then toggle the server on by typing in command palette `LSP: Enable Language Server Globally` or `LSP: Enable Language Server in Project`.
Copy link
Contributor

@bnbarham bnbarham May 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC LSP-SourceKit is a small amount of configuration to enable sourcekit-lsp (which could be done in the LSP configuration)? And Swift-Next adds grammar files (vs the old https://github.com/quiqueg/Swift-Sublime-Package and https://github.com/colinta/decent-swift-syntax)?

If so, I think we should re-word this slightly to something like:

Before using SourceKit-LSP with Sublime Text, you will need to install the LSP from Package Control. From there you can either manually configure Swift and C-family languages to use sourcekit-lsp, or use a community-provided package to set this up automatically (eg. LSP-SourceKit).

For syntax highlighting, how does this interact with the semantic highlighting provided by LSP? Is it merged after the response comes back? Something else? Depending on that we could also add eg.

Swift-Next (another community-provided package) can also be added for syntax highlighting prior to Sublime receiving a response from the LSP server.

EDIT: I just realized the above thread is all about this. Sounds like it isn't just for highlighting prior to the LSP response, but in any case, mentioning some summary of that would be useful here IMO.

Not for you in this PR, but we probably need to got through this doc and clear it up for the other editors in general 😅.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Swift docs update

Ah sheesh, here we go again 😅

So let's break it down from top to bottom in one place

LSP-SourceKit package purpose

LSP-SourceKit is a small amount of configuration to enable sourcekit-lsp (which could be done in the LSP configuration)?

It's no. It was so a while ago, but for at least a few years now it has been handled by a separate LSP-ServerName packages. As mentioned in a note on a link you provided in your suggested change snippet:

The external LSP-* helper packages already come with their setting file and a client configuration and you don't need to add anything to the global LSP settings. This section is only relevant if you want to add a new client configuration for a server that doesn't have a corresponding helper package.

So since we're having LSP-SourceKit helper package this is the main way to interact with a sourcekit-lsp server for ST4 user.

LSP-SourceKit maintaince

or use a community-provided package to set this up automatically (eg. LSP-SourceKit).

Technically speaking all the LSP stack for Sublime Text is community provided, including the main LSP itself. The main LSP package, along with the LSP-SourceKit helper, is stored in the same group on GitHub. Therefore, it makes sense to consider them both as either semi-official or community-driven simultaneously.

C family language support

either ... Swift and C-family languages to use sourcekit-lsp

This is true, the default configuration of LSP-SourceKit package is set to support all c, c++, objc, objc++ and swift. And at the same time this is the reason why the plugin installs in it's disabled state. We had long discussion about how to make it best and conclude that this is the best scenario from UX perspective.

To elaborate, most ST users unaware of sourcekit-lsp capabilities to support c family languages, and they can use clang for that purpose in their swift-unrelated projects. So, this bit says no to either include c, c++ into LSP-SourceKit default scope or toggle it on by default.

From the other perspective, if to exclude those scopes from the default setup, ST barely could differentiate c/c++ header file from objc one, which leads to it will not call this server for objc headers if they are appeared in project without additional user's effort to setup scope properly. And this is requires more effort that just run a single command from within command palette to explicitly toggle this server for a project or globally.

This is how we went here. To include the full list of scopes that sourcekit-lsp supports in the default setup, but to toggle them off on installation, to not break other plain c/cpp projects.

Miscellaneous Syntax highlighting questions

Various ST swift syntax packages

And Swift-Next adds grammar files (vs the old https://github.com/quiqueg/Swift-Sublime-Package and https://github.com/colinta/decent-swift-syntax)?

That's right. ST suffered from a very limited swift syntax highlight support until Swift-Next release, which is finally quite mature in just this. Now this package is on its (long) way to being included in predefined packages list

As my college claimed above the one grammar file is strictly required to make LSP helper package work. So me and ST team are suggesting this one among the others.

Semantic syntax highlight support

For syntax highlighting, how does this interact with the semantic highlighting provided by LSP? Is it merged after the response comes back?

Yep, grammar loads first, almost instantly on a file open, then, it could be expanded with semantic syntax tokens provided by a server. Now this feature disabled by default (to the LSP package in general). I've tried to enable this for swift sources and have to say it's pretty useless for ST for now, as this kind of syntax highlight just make things worst comparing to a grammar one. Didn't dig deep enough yet, but I believe the cause is that there is token naming mismatch between those that server sending and ST are working with.

EDIT: Various English grammar fixes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't dig deep enough yet, but I believe the cause is that there is token naming mismatch between those that server sending and ST are working with.

Ah, I wonder if this was while we had an extra kind inbetween the built-in ones. Technically this is allowed by the spec, but most clients seem to ignore the mapping 😅. That was changed in #1012.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, yeah, it was definitely after that PR, like a few weeks ago. It's because before that LSP package had a bug that broke swift semantics syntax highlight completely 😅.

Now it's fixed, but yet if to enable it's literally colors almost all the tokens in the same color for a vast majority of ST color schemes that I've tried.

I saw an option to remap tokens names right within LSP helper scope, so I think it could be a solution to that.


## Emacs

Expand Down