FWIW, here are all the IDE-like libraries for Swift that Valentin Knabel and I have found.
From them:
btw it’s language-swift89 not language-swiftt89 :)
Great job! 
As a curiosity, why are language-swift-89, atom-ide-ui, tool-bar not defined in the package.json manifest as dependencies?
As I understand it, the dependencies part of package.json is actually for node modules, and not for listing dependent packages.
There is however a package-deps section, and I forgot to list language-swift-89 there - I'll fix that, thanks. I'm not actually sure if apm uses that entry to actually install things though - but it's at least a way of documenting them.
details, details...
i think the IDE doesn’t actually need the syntax highlighter,, it’s just a lot more pleasant to use with it lol
Yeah, you may be right.
I was thinking that it might need something to tell it about the existence of .source.swift and source.lang.swift, but actually I now realise that I was thinking about the auto-completion plugin.
In any case, life is much nicer with syntax highlighting, so I might pretend that it needs it ;)
can you show me how to make requests into SourceKit? I looked through this but it doesn’t exactly tell you how to do it from code
In the autocomplete package that I put together, I did it via sourcekitten. That makes life relatively easy, if you're ok with the overhead of calling out to a separate process, and the need to have a dependency on it being installed.
If you want to call SourceKit directly from Swift, your best bet is probably to look at the sourcekitten code, but it's fairly dense :)
I also just came across this in the SourceKit code, which looks like it may be aimed at adding a direct Swift interface. I'm not sure what the status of that is, but it would be useful if it simplified things.
There is also actually something called sourcekitd-test, which is built as part of SourceKit, and looks similar to sourcekitten.
Currently it isn't bundled with Swift distributions, but there's a thread requesting that it should be. It would certainly help if it removed the need for an external dependency (eg sourcekitten).
I was able to get a simple C program calling into libSourceKitInProc.so running so the next step is basically getting it to compile under node.js and apm and writing the javascript nan bindings for it. SourceKit is actually really really easy to use, it’s a shame the documentation is so poor.
Weird. It looks like SourceKit is actually inferior to many text editor syntax highlighters in the number of different things it can identify. It can’t separate out function calls from ordinary variable identifiers, or “special” builtins like self or $0. It doesn’t know about standard library symbols like abs(_:) or min(_:_:). The only place it seems to outperform regex-based highlighters is it can tell the difference between type identifiers and regular identifiers, and it can highlight string interpolations…
IMHO none of those are something that should receive special treatment…
i think basically every editor and most users agreed they are?
That is... non-optimal.
I agree that you really want to be able to categorise things as finely as possible (even if you then map some of them to the same appearance on your syntax theme).
With the standard library stuff, does it maybe work if you actually have an import of the relevant library in the file? I found that was how it works for auto-completion (which is good, I think).
sourcekit exposes about 20 species of syntax tokens. most of them have to do with attributes, the preprocessor, and doc comments, so “normal” code really only gets sorted into identifiers, types, keywords, numeric literals, strings, and string interpolation anchors
