VSCode Language Server Protocol for Elements

Elements
, , , ,
1

VSCode (Visual Studio Code from Microsoft - https://code.visualstudio.com/) is a powerful, open-source, cross-platform lean editor built on web technologies (NodeJS, TypeScript, ElectronJS) supporting extensions (for language, tools, UI).

In regard of language support they introduced a generic JSON-RPC driven language server protocol that can use any backend (ex: NodeJS, .NET, Java …etc) that decouples the editor bound features (completion, errors, linting, compilation, debugging, etc …) from the language compiler implementation.

As a result, instead of using TypeScript (as for regular VSCode extensions) the language server may be written in any language/runtime (ex: stick to Oxygene, C#, Swift …etc) as long as implements the Language Server Protocol.

With all these benefits, exposing the Elements compilers as a VSCode Language server may be a very good addition into the Elements toolbox.

Here are some relevant links in this context:

Creating Language Servers for Visual Studio Code

Language Server implemented in NodeJS & TypeScript


Language Server Protocol


OmniSharp - Official .NET, C#, Roslyn support for VSCode
https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp




OmniPascal - Delphi and Free Pascal support in Visual Studio Code
https://marketplace.visualstudio.com/items?itemName=Wosi.omnipascal
http://www.omnipascal.com/
http://blog.omnipascal.com/
https://bitbucket.org/Wosi/omnipascal/

Java support for VSCode
https://marketplace.visualstudio.com/items?itemName=redhat.java


1 Like
2

supporting a new IDE is a lot of work. for now, we’re focusing on VS on Windows and Fire on Mac, and i think we have a pretty good IDE story with that, for Elements.

3

Starting with providing some documentation pointers for Elements compiler CLI (& any API integration) may help to bootstrap the actual work (by community) for such VSCode support.

4

I could not agree more

5

There’s no public API to document. The closes would be the FireProjectSystem that drives Fire and Water (and is distinct from VS’s), but right bow that’s a private APOI and too much in flux as that i’d want to inflict it on anyone outside of to develop against it.

Maybe some time in the future but right nw we’re focused on Fire, Water and VS as our IDEs.

What upside do you see to using VSCode over Fire (aside from levering it to making better use of all that RAM Macs have these days, which Fire just doesn’t manage to fill up as good as apps written in web technologies manage to ;)?

6

Then please enhance text editor modules.
At least support multi language input.
Even open source languages like Nim and Crystal supports VS Code.
I love to use them on VS code.
and i also hope that I could use Elements in VS Code.

7

What specifically are you missing for the text editor? i’d love feedback and ideas how to improve it further.

8

There are new many things like

multiple tab
Multiple caret
Split view
Git integration
Asian character input
Mini map
and many small things… (Wrap a selection by quotation or bracket)
People loves their text editor for their small preferences.
Thay’s why Language server gives alots of freedom.

For example, Nimlang has their own Editor and community made VS code extension.
Dartlang had their own DartEditor and gave up and support intelliJ and community also made VS code extension
Crystal Lang has VS code extension too.

I believe that a Language Server is essential to grow a ecosystem.
I followed Remobjects to change over a year.
Closeness is not good for grow a ecosystem.
I think i have to give up my first cross platform language.

Thank you.

1 Like
9

openness != having to support every IDE under the sun.

everyone’s got their favorite, as you say, but we cannot support em all. we have three superb IDE options (two shipping now, one coming). that’s quite a lot for a team of less than 10 people, i’d say.

We’ll keep improving all three, but adding a fourth (and a fifth and so on, because people also want us to integrate into IntelliJ, and Xcode and…) is simply not a feasible option right now. And if it was, it’d not be VSCode, not after the year of hell that VS2017 has just put (and still is putting) us thru. sorry.

sorry to hear this, but everyone needs to set their priorities, bruit we cannot set ours to align with everyone’s. You need to decide for yourself if using VSCode is more important for you than using the language you (presumable) like. It seems like an odd priority to me. Personally, i’d rather code a language i like in notepad, than one i dislike in Fire.

10

FYI.
I really love Elements.

My biggest block to use Elements further is

Strangely, I found that Xarmarin for mac has same issue for korean input.

11

Yeah, i’s right now at a dead end for supporting that. i cannot find any docs on how this works at the level that our text editor handles keyboard events. Finding the info for dead-key support was rtrickty (thats “Option-U, U” giving you a combined “ü”).

i tried exploring along similar pathways but for korean i don’t even GET a keyboard layout object, which is what that code uses (in fact, testing with korean let me find a few crashes potential crashes in the editor’s dead key support because it issued it waked always have one ;).

my nest step would be to open a support request with Apple i guess.