Common language extension features and porting to-and-from Atom and VSCode

Basically I happened upon language-algol60 on VSCode and it lead me to Atom. This was because the grammar, settings and snippets json files are compatible with both VSCode and Atom.

I have a few questions:

  • How many other language-extensions run on both VSCode and Atom?
  • Does Atom’s language-python, language-javascript, language-c and language-ada run on VSCode? (portable)
  • Which “portable” language-extension would be the most feature rich and/or mature? (I’m looking for such an extension in the hope I can learn from it and it’s sourcecode & json files.

ps. I’ve already managed to pull together an extension VSCode and Atom that works. And hoping to leverage on the above questions/answers to do a nice job.

The grammar packages are portable because both Atom and VS Code use the same grammar definition (TextMate grammars). Atom has since added support for Tree-sitter grammars that are more powerful (there are a lot of bugs in TextMate grammars that are impossible to fix, or too impractical / edge case-y to be worth it), but are also more complicated to write.

In fact, until recently VS Code used Atom packages for most of it’s base syntax highlighting (semantic highlighting is VS Code specific though). I believe they may be maintaining their own forks of them now though, as Atom isn’t maintaining TextMate grammars when the Tree-sitter version exists.

As for other things, snippets are roughly the same, though VS Code is a bit more powerful in terms of raw snippet capabilities (for now, I’m hoping to fix that up at some point). Fancy functionality in Atom is done using an autocomplete provider instead (basically, programmatically compute a snippet when needed).

Outside of that, you will at least need a compatibility layer for a package to work on Atom and VS Code. The APIs are just too different. They are both Electron apps though, so you can share some components easily (e.g., make the foo NPM library and have separate atom-foo and vscode-foo packages that use it).

The APIs are just too different.

Keep in mind that if Atom and VSCode are both installed you can use an automation script to jump from one development environment to another through the higher level UI operations. This approach does not require low level API compatibility.
I offered one such idea in an earlier thread “Atom and VSCode in tandem”. For example VSCode has a much better engineered HaXe extension. I can write code in Atom and switch to VSCode quite smoothly. Get the best of both worlds.

We are talking about writing packages that work for both, not using both for their different packages.

I am writing about processes that work for both. Packages are a means to an end.

Thank you all, for all your insights… I am new to these language extensions in both VSCode and Atom, … so these type of extensions are still “mostly greek” for me.

I’ve downloaded MagicPython and will read through it’s source… I picked MagicPython because it runs in Sublime Text, Atom and Visual Studio Code … and so (I guestimate) I can best(?) learn from its implementation.

MagicPython is very complex compared to writing a grammar directly. It appears to define the grammar in a set of files (maybe Sublime Text compatible?), then run a build script to compile it into Atom & VS Code compatible files. Sublime Text itself has the same base (TextMate compatible) grammar engine, but I believe it’s been extended significantly to the point that grammars for Sublime may not be able to be translated to Atom / VS Code grammars.

But MagicPython is just a grammar + snippets package, so it’s much easier for them to work across editors. My point about requiring different “front ends” to interact with the editor APIs still applies.

To answer your original question though, if grammars are all you care about, then targeting TextMate grammars will be the most portable across the editors you’ve mentioned.

1 Like

I’m the author of one extension for both editors: the APIs are completely different in most ways, and probably not easily portable.

What I did was to implement a compatibility layer for both packages, and even then it’s not that easy - for example, in Atom you can change almost any UI element. On VSCode, there’s an API to make it that allows you to write… a webview. That’s exactly like a web browser in almost every way, except that’s more restrictive.

I was also trying to extract some of these “compatibility layer” to another package, but it’s very hard to do if you just want to write “a generic” package :frowning: