adds Swift support

[colinta]

This is based on my "Swift for **ing Sublime package" (named so because I was frustrated with other packages). This uses the new .sublime-syntax format, which I've been loving. Some notable features:

Good support for "Go to symbol", including matching the // MARK: that Swift uses as a "goto label" feature. Also supported are the long method names that swift uses.

Notably missing from the "Go to symbol" feature is the ability to go to var foo in a class or struct body. Especially useful if the var foo is a computed property (e.g. var foo: String { return ... })

[Gerst20051]

👍

[wbond]

@colinta Is this something you are still interested in contributing? Have there been many changes to the language recently?

[colinta]

Oh yeah I still maintain my swift language syntax. Very few changes recently, just keywords mostly.

Still haven't taken the time to get class properties to appear in the "go to symbol" menu, that's the only bug.

On Feb 16, 2016, at 12:44 PM, Will Bond notifications@github.com wrote:

@colinta Is this something you are still interested in contributing? Have there been many changes to the language recently?

―
Reply to this email directly or view it on GitHub.

[colinta]

I'll push up my recent changes.

On Feb 16, 2016, at 12:44 PM, Will Bond notifications@github.com wrote:

@colinta Is this something you are still interested in contributing? Have there been many changes to the language recently?

―
Reply to this email directly or view it on GitHub.

[colinta]

ok @wbond I've pushed my latest, is there anything I can do to make this easier to merge or maintain?

[colinta]

(rebased to clean commits)

[colinta]

@wbond Still would like to see this merged - Swift support! Anything I can do to improve this?

[wbond]

Yes, I am planning on getting to this. I haven't had a change to look yet, but if you could run the new "Regex Compatibility" variant of the Syntax Tests build system on it, then we can get an idea of any incompatibility with the new regex engine. It is available in build 3109.

We are moving all of the default packages to compatibility with that to improve performance of rendering and indexing. If there are any incompatibilities, post them here and I may be able to give suggestions on how to work around them. Generally they should just be look behinds and backreferences. Other incompatibilities we may be able to resolve by improving the new regex engine.

[colinta]

Just a couple lookbehinds, I can take care of those.

[colinta]

Success: all patterns in "Packages/Swift-for-f-ing-sublime/Swift.sublime-syntax" are compatible with the new regex engine

[colinta]

Btw that's the test of my swift package - I copied that sublime-syntax file into this PR (and, again, rebased).

[colinta]

Another fix and rebase. Tests still pass as expected, should be good to merge! Thanks again for all the help @wbond!

[wbond]

This looks like a solid start.

Recently I rewrote the Rust and C++ syntaxes, so I've been working with implementing support for similar languages, and have learned a lot along the way.

I spent time perusing https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html a little bit to learn more about the language syntax and features.

From going through that, I think there is still a good amount to cover, plus there are scopes that we should add because we are including them in languages that are part of the default packages. This list isn't exhaustive since I haven't gone through the whole language yet. Additionally, this isn't a request for you to add support for all of these, but it is a list of things that should be added by someone (you, myself, or someone else).

• Meta scopes on blocks
• Punctuation scopes on {, }, :, (, )
• Distinction between : in ternary operator and as a separator in class definitions and as a type separator for variable/constant declarations
• Scope on generics and the < and > that are part of them (so they aren't scoped as operators)
• Closures
• Unicode escapes in strings
• Nested block comments
• Optional types (it wasn't clear to me if this was implemented yet)

[colinta]

If you have a sec, let me know what the scope names are for these, I'm taking a stab at it now.

[FichteFoll]

You could take a look at the C family syntaxes, which are the most recently updated ones and include the first four things mentioned.

[colinta]

Thanks @FichteFoll, I'll keep that one in mind!

One thing that's got me scratching my head, wondering how this could be approached:

func foo(a: Int) -> Int { return 0 }
//       ^^^^^^ "function params" scope
//                      ^^^^^^^^^^^^ "function body" scope

How can I "push" these two scopes? Right now, I've got something like this:

contexts:
  main:
    - match: '\b(func|operator)\s+(\w+)\s*\('
      captures:
        1: storage.type.function
        2: entity.name.function variable.function
      push: function_params
  function_params:
    - include: main
    - meta_scope: meta.function meta.toc-list
    - match: '\)'
      pop: true

[keith-hall]

@wbond is the info here about accepting new packages no longer relevant? have you made the planned changes?

[wbond]

@keith-hall Currently we’ve decided to add Rust (which is already complete) and Swift support. The technical solution is in place to make sure default packages don’t cause issues with .sublime-package files of the same name installed to the Installed Packages/ folder by Package Control.

There still needs to be some testing to ensure that Package Control can uninstall a package with the same name as a default package.

Other than Rust and Swift, we do not currently have plans to add any other default packages.

[keith-hall]

@wbond cool, thanks for info :)

[FichteFoll]

Just tried using this since the current Swift syntax definitions on Package Control are definitely lackluster. However, this also needs more work.

• I get a lot of invalid scopes (that don't necessarily indicate where they come from since the scope names are really just invalid) on various whitespace characters. This is definitely over-eager and I removed most of those matches for now.
• Scoping is kinda inconsistent with enum member definitions getting variable.other (and that in general being used quite often).
• Punctuation isn't scoped, or incorrectly (as keyword.type for example).
  Class variables are seemingly ignored entirely as they only get meta.toc-list, but for both the name and the type.
• No scope has the trailing basename swift. This is useful to only taget numerics in swift, for example.
• There's some random testing meta scope.
• for in a function call like peripheral.readValue(for: cmd_characteristic) is matched as a keyword and breaks highlighting slightly (closing paren is matched as stray/illegal).
• Signatures with some named arguments (I haven't used Swift enough to understand what these actually are) are highlighted as invalid. Example:

      func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {}

• let and var should be storage.type, not keyword.variable.
• The . accessor should be scoped as punctuation.accessor.dot.swift, not as keyword.operator.accessor.
• ? and ! aren't recognized properly in type declarations. They are scoped as ternary and unary (?) operators instead.

That should cover most of it.

[FichteFoll]

Here's a screenshot with perfectly valid Swift code highlighted with the syntax definition in this PR:

[FichteFoll]

GregoryBL's syntax is much better in this regard (even compared to the "Swift for f*ing Sublime" base) and can definitely be used as a base. However:

• Type declarations in function signatures should be support.type, not entity.name.class (and for this named arguments thing I mentioned earlier it probably shouldn't be entity.name.function).
• Neither should class instantiation be highlighted as entity.name.class.
• Enum bodies aren't highlighted at all.
• The init constructor funtion definition isn't matched.
• The ! operator isn't matched.
• It uses lookbehinds.

I firmly believe that the current state of this PR can be disregarded and closed.

[colinta]

@FichteFoll I dunno why your syntax highlighting is so screwed up, but on my machine that same code looks fine. I also checked the syntax for red flags but nothing comes up as strange. I'm guessing that the color scheme you're using highlights meta.function or meta.toc-list strangely? Dunno.

I think your criticisms here are unnecessary/redundant, since this conversation has turned from "here's one to merge" to "how/when can we have an official language definition". If you find bugs in my package I think opening an issue on that repo would be the appropriate place.

I also like GregoryBL's syntax, so without tossing around additional unnecessary hyperbole I'll just add that having an "official" Swift syntax that is included out of the box would be great. There are multiple Swift syntaxes out there, with a mix of support / features, and I have to assume that it's confusing for people who just want to have a syntax that "just works".

[colinta]

Actually I'm gonna close this PR entirely - I don't intend to edit my own package just to adhere to standards that I am having a really hard time compiling, and it's not in a state that makes it ready "as is", either. I'll leave it to others to pick this up.

[wbond]

@GregoryBL Are you interested in submitting your Swift syntax as a PR and working with the contributors to refine it for inclusion? If so, please open a PR and we can move from there.

Sorry this got so dragged out @colinta. I appreciate the effort you put in, and hopefully we'll have a solid default Swift syntax in the default packages before the next stable release.

[FichteFoll]

Since I've been doing some swift lately, I'll see whether I can set aside some time in the next weeks to work on a default Swift syntax.

[GregoryBL]

@wbond I haven't worked on it for a while (several major swift versions), but I'll work on getting it together for a PR this weekend.

[mortenholmgaard]

Any news on this?

[soynomm]

Also interested

[wmorgue]

👋🏻 from 2k20.
Any news?

[wbond]

Based on the fact that there haven't been any posts here, I don't think anyone is working on this.

If someone is keen on having this out of the box and knows Swift fairly well, the ST Discord server is probably a good place to get some support in terms of writing a good .sublime-syntax that we would be willing to add to the default packages.

[jrappen]

which can be found here:

[luckman212]

Since this as well as #253 are closed, is there any other place to track (potential) progress on Swift support for ST3 / ST4?

[michaelblyons]

@luckman212 Install Colin's package? https://packagecontrol.io/packages/Decent%20Swift%20Syntax

[bojanpotocnik]

Based on the fact that there haven't been any posts here, I don't think anyone is working on this.

Too bad, as it seems based on the decent-swift-syntax's commits that Colin actually still maintains this plugin.

[frou]

The Swift.tmLanguage syntax in TextMate's Swift Package is maintained. But when picking that file out and putting it in my User package in Sublime Text, I can't get it to be recognised. Is it too heavyweight (5000+ lines)?

EDIT: Although it had some recent-ish commits, in reality it's not particularly maintained (from looking at the full commit history). Sorry for the false alarm.

[wbond]

Do you see errors in your console @frou?

[frou]

Yes actually. I did look before but evidently it was easy to miss:

error parsing lexer: Packages/User/Swift.tmLanguage: Unexpected capture value

[wbond]

My hunch would be that TextMate has had its own .tmLanguage additions that we don't support. It appears some captures include a patterns structure instead of a dict with a name and scope name.

[ccampbell]

I just opened a pull request on @GregoryBL’s syntax to try to make things a bit more in line with other Sublime Text grammar conventions. It is not exhaustive by any means, but it should be a step in the right direction at least as far as the scopes are concerned. I’m sure there are some language features still missing, but you gotta start somewhere.