Something that I've really not seen mentioned, is that they are also (and still!) ignoring the licensing that Microsoft has around VSCode.
VSCode is built on open source of course, but the the OSS version is "Code - OSS". When Microsoft builds it and releases it, it becomes VSCode with the Visual Studio trademark and what not.
PearAI's Code fork is using the real VSCode marketplace which has strict "This has to be used with Visual Studio products" (well, and some other MS / GitHub bits), so they can't use that. If you look at other VSCode-adjacent editors, they all use open-vsix.org instead.
They also use extensions that are licensed in the same way:
They have instructions on setting up the WSL extension...which has a "This can only be used in Visual Studio Code" License too, so it can't be used in their PearAI fork.
You can see some examples of the terms of use / LICENSEs here:
We host the VSCode extension host, which is how Oni2 can use VSCode extensions.
I.e, the whole front end and core editor is native code (ReasonML/C), and then there is a nicely typed interface where we communicate with a node instance to run VSCode extensions. We broadly end up with Oni2 <-> Ext Host <-> Extension.
We have to implement the Oni2 side for each thing, so parse the message sent, and how to action on that and render it, but it lets us run VSCode extensions, still in a native editor.
There are some caveats, like the license issue mentioned, the largest being that extensions that heavily depend on rendering custom components / web pages aren't possible, just since Revery has no browser etc to render anything like that with.
We've focused on language ones to start though, and that has meant we support a decent selection of langauges as adding one feature unblocks loads of extensions.
Its written mostly in ReasonML (syntax for OCaml) with a bunch of C-libs wrapped in OCaml (Skia/Harfbuzz/SDL2 etc), so it compiles properly to native in the same way that normal OCaml code would.
The only JS in Revery is for some utility scripts and some aroud an option to compile to JS (which isn't functional at the moment, but the idea being you could compile to JS if you wished, with stubs to fill in the blanks for API calls that would normally hit Skia etc).
> Just saw that it is actually open source and will be available for non-commercial use for free. I'm more than fine with that model!
Yeah, we are using the dual-licensing model that some other projects use.
Source available may be a more accurate description, since it can be somewhat controversial to claim to be open source and use our licensing model.
Tl;dr:
- Commits from the core team are licensed under an EULA for 18 months. You can use Oni2 for free for non-commercial stuff, but need a license for commercial use.
- After 18 months, commits are re-licensed to MIT license, and appear in the Oni2-MIT repo, where they are then subject to the normal rules of that license.
We do also periodically give to the upstream projects that power us, i.e. you'll see our name in the Vim leaderboard thingy since we give money to the charity that Vim asks for donations to.
And to be clear, whilst we use the vim source code as the editing experience base, the UI is our own, thought obviously looks very similar to VSCode, though no UI code is shared etc (Oni2 is written in Reason, VSCode in Typescript).
> but implementing a vim backend is a monumental task if you intend to be compatible with existing vim plugins
We skipped that and haven't implemented any vim backend at all!
We use/made libvim[1], which is just the vim source, that we've essentially turned into a library. So its the vim code base with terminal UI stuff stripped out, and an interface added for us to hook into it. The README of that repo has some good insight into that (including why we didn't use neovim here, as much as the team all loves nvim).
We don't support vimscript stuff at the moment, but its in progress as all the vim source code is there to load/run it as normal, its just about integrating is properly into Oni2 (making sure keybinds are working, commands are properly loaded, packing stuff up nicely for distrib etc).
(There is some other motivation bits in this doc[2]. Its outdated since we haven't edited it since before the project started, but it outlines the motivations we went in with etc).
Oni2 is available for use for free for non-commercial usage, it just needs building from source at the moment. The steps are in the user manual if anyone is interested: https://onivim.github.io/docs/for-developers/building
Partially that is a thank you to those who have supported our development, and partially its to help put up a small barrier to entry, just so we don't get too flooded with issues and feature requests!
A public release is coming soon-ish, and can be used for non-commercial use.
This isn't technically true, the extension host we use is directly the one from VSCode, such that we can support their extensions (well...a subset as we fill in the gaps in for the Oni2 <-> ExtHost communication).
But the actual core editor is all seperate, written in ReasonML (or OCaml if you know that instead), with a bunch of C libs in the background we've wrapped (Skia/Harfbuzz/We wrap real vim etc).
So the core editing experience has no code sharing, but the extension side of things does!
Its a workflow we are looking into supporting, but its difficult. VSCode has extensions that are licenesed in a different way to the rest, which includes all the remote development ones (WSL/SSH/Docker).
Their license can be found on the marketplace, but broadly they can "only be used with Visual Studio Family products" (or something of similar wording, i.e. Code only, some are VS only). They are also fully closed source as well, the GH repos are just for issues.
So we'd like to support that sort of workflow, but it will mean more work on our end since we can't use that existing work due to the license.
Yeah, I would say that I don't think I've joined Zoom and used it that way, its almost always either a set scheduled meeting where there is a dedicated room, or just an always up room that you join at a given time for more ad-hoc meetings.
At least part of the issue will probably be the disconnect between that style of more "work" usage and the fact its become tool at the moment for families to connect. In that regard, going through the UI as shown may be more common, and does have some more issues, though its also maybe less of a focus for a more work-focused tool.
It does seem to be decent enough for the non-host at least, where if they just blindly press the blue button on entering they'll be in the call/waiting room, which is at least fairly frictionless from a non-host point of view, and for me the bigger concern. I can deal with the UI, I'm more worried about my Grandpa or something working it out if I was doing a family call.
- We moved from Typescript/Electron to ReasonML/Revery for a native rendering stack which is much faster (startup/in general) and generally lighter weight, with a solid FFI story for native libs (Like libvim below, but also stuff like tree-sitter etc).
- We moved from neovim via RPC to libvim, a fork of vim as a library, with motivation behind that change in the doc above, and why vim over nvim in the GitHub README for libvim.
This is allowing us to bring forward the things people liked in Oni1, but drop stuff that people didn't, with Electron being an obvious big one. The end result, combined with harnessing the VSCode ecosystem should hopefully make a compelling editor.
We are adding Vim-style tabs as well (i.e. tabs are a view on to buffers, where a buffer can be any split etc as expected).
That said, you are right that a lot of people in Oni1 were interested in a "modern" (in heavy quotes there) way of doing tabs, where a split could have its own tabs etc, as is the way in VSCode etc.
VSCode is built on open source of course, but the the OSS version is "Code - OSS". When Microsoft builds it and releases it, it becomes VSCode with the Visual Studio trademark and what not.
PearAI's Code fork is using the real VSCode marketplace which has strict "This has to be used with Visual Studio products" (well, and some other MS / GitHub bits), so they can't use that. If you look at other VSCode-adjacent editors, they all use open-vsix.org instead.
They also use extensions that are licensed in the same way:
https://trypear.ai/blog/wsl-setup
They have instructions on setting up the WSL extension...which has a "This can only be used in Visual Studio Code" License too, so it can't be used in their PearAI fork.
You can see some examples of the terms of use / LICENSEs here:
https://cdn.vsassets.io/v/M190_20210811.1/_content/Microsoft...
https://marketplace.visualstudio.com/items/ms-vscode-remote....
It just shows a complete lack of regard for licensing...