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'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...]
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).
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?
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