Hey
I wrote a tiny atom plugin which enables building and debugging
swift packages (using SPM) from inside atom.
Here is the blog post with tutorial
https://medium.com/@Aciid/hacking-atom-to-create-a-swift-ide-that-runs-on-linux-and-mac-c7d9520a0fac#.ytedt4uh9
--
Ankit
Oh great ! Thanks for sharing !
--
Pierre
Le 12 déc. 2015 à 18:28, Ankit Agarwal via swift-users <swift-users@swift.org> a écrit :
Hey
I wrote a tiny atom plugin which enables building and debugging swift packages (using SPM) from inside atom.
Here is the blog post with tutorial
https://medium.com/@Aciid/hacking-atom-to-create-a-swift-ide-that-runs-on-linux-and-mac-c7d9520a0fac#.ytedt4uh9--
Ankit_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
I've been hacking around with a fork of this a bit lately.
I'm thinking of continuing to work on it (and possibly renaming it as it's rapidly diverging from @Aciid's original code).
I'm working on Linux at the moment, and options for IDEs are limited.
I've also got an Atom swift auto-completion plugin working (for me) on Linux.
I know that Nuclide has some support in Atom, but I'd quite like something a bit lighter. It's also just interesting to hack around with :)
If anyone has any interest in such a project, or feedback, please shout.
The projects are very much at the "well it works on my machine" level of polish right now...
Wow, this is "a blast from the past".
It'll be awesome to have an editor with debugger support for Linux! The original code was some random hacking I did in my free time. I can transfer the ownership of my repository if you're interested in using the same name.
It was an excellent place to start, so thanks for the random hacking 
.
Thanks!
I'm not quite sure how the package "publishing" model works with Atom, so I don't know if it would simplify things to transfer the ownership, or if it'll actually confuse everything if the github repo moves?
In some ways it might be clearer for me to come up with a different name and publish what I'm doing as a new package (acknowledging the debt to your original one, of course 
).
I'll have a think...
I've also been wondering whether to consolidate the debugger, syntax highlighting, and auto-completion into a single package.
I like the idea of multiple packages - from the "do one thing, do it well" point of view - and of course in theory it means that multiple people can maintain them.
On the other hand, it's easier for the user to just install one package perhaps? I think it depends a bit on whether anyone else is really active in this space. Apart from just being for the fun of it, the main reason I'm contemplating this is that there doesn't seem to be a lot else out there for Linux right now.
[to be clear, I've spent the last 30 years as a Mac developer, so it's not like I'm some sort of Linux guru . I'm experimenting with spending more time in Linux at the moment though...]
well, it’s mine lol
phew, lucky I said the right thing then
I'm using that one now...
its fine lol i want to replace the regex highlighting with actual sourcekit tokens (because the highlighting is still a little faulty) but atom makes it so hard to use external tokenizers. this is why i keep reminding people proposing complicated syntax to add to the language that literally every editor except xcode still parses with regexes.
From the packages I've seen, the convention seems to be to have a language-$lang package including the syntax definitions (some also have snippets), and another package for completion, debugging etc.
Atom has recently launched some support for these types of language integration packages, https://ide.atom.io/, building on top of the language server protocol. Packages that support this are then called ide-$lang (https://atom.io/packages/search?q=ide).
I'd love to have a proper Atom IDE package for Swift. There are some LSP implementations out there, https://github.com/owensd/swift-langsrv and https://github.com/RLovelett/langserver-swift (see also VS Code language protocol), but I'm not sure how many of the LSP features they support.
Yes, on reflection I think it's better to stick to this convention, and treat the various parts of the problem separately.
I've also realised that a large part of what I'm building is actually generalisable as atom-lldb, so I'm considering splitting it further. This appears to be the approach taken by VisualStudio Code.
This would leave us with potentially four components:
Right, yeah, I was wondering why nobody was using SourceKit to do the highlighting, but haven't got round to looking into how the Atom side of it actually works.
Do you think the performance of a SourceKit approach would be acceptable, assuming that the plumbing could be sorted out?
Ah, I didn't know about that, I'll take a look at it. I wonder if they have subsumed more of Nuclide into the Atom core, or if this is something new.
Yeah, it sounds like ide-swift is perhaps what I should be aiming for.
I looked into David Owen's LSP stuff (also, going the VS Code route completely). My feeling, from a brief examination of it all was that there's nothing reliable working on Linux yet, and that the mental overhead of LSP was more than I wanted to take on right now. Also, David has been assimilated into the mothership, which doesn't help :)
Starting, as I have, by hacking together a standalone autocompletion package, and then iterating on @Aciid's starting point, felt like an easier way in.
I have the luxury of being able to dedicate my time to this at the moment (if I want to), so I'm not completely against the idea of LSP or something else a bit less hacky - but I confess I'm tempted to keep iterating with what I have for a while and see where it takes me.
Hmm... after taking a brief look at the IDE stuff, it does look like it provides most if not all of the plumbing that I was considering trying to build myself, so it would probably be crazy not to use it. Which probably pushes things down the LSP route. 
That said, I'm hoping that it should be possible to hook up to the Atom IDE services in a piecemeal fashion. If I can start with the debugger support - which is essentially what I've been starting to develop myself - then I may be able to do that and worry about LSP things later.
i looked everything over and it looks like LSP intentionally doesn’t support syntax highlighting. So while it would be useful for example for bringing compiler warnings and errors into the Atom interface (no more super-tabbing between atom and the terminal!) it can’t be used for syntax highlighting.
I can remember exactly one language which was able to overcome this and it’s Typescript, because someone was smart enough to figure out how to turn off Atom’s native highlighter and replace it with a javascript package that modifies the UI in such a way that looks like syntax highlighting. Maybe that’s the only way here
update: this is definitely possible and i think i know how to do it. stay tuned layteas