Thanks, I've been using this, but the one you linked to looks like it's a bit more up to date.
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 (Search Packages).
I'd love to have a proper Atom IDE package for Swift. There are some LSP implementations out there, GitHub - owensd/swift-langsrv: The language service implementation for VS Code. and GitHub - RLovelett/langserver-swift: A Swift implementation of the open Language Server Protocol. (see also VS Code language protocol - #6 by tonyarnold), 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.
update: this is definitely possible and i think i know how to do it. stay tuned layteas
FWIW, here are all the IDE-like libraries for Swift that Valentin Knabel and I have found.
- langserver-swift needs yet-unimplemented Foundation features. It implements the LSP.
- SKD needs a little push. It can be integrated with any text editor.
- SDE is for VSCode only afaik, but it works on Linux
Very, very rough, but it's a start.
As a curiosity, why are
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.