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:
I've interviewed for Coinbase and it was a shit show. The recruiter initially said my interviews went well but then never got back to me, even after me reaching out multiple times. Plus there are lots of reports from people working there that things are held together by strings and glue, and the work life balance is terrible.
I imagine coinbase has a legal department and these guys were paid to code.
Using chatgpt to write a license is a ridiculously dumb thing to do since there are so many public templates to choose from, it sounds like they're just overly enthusiastic about AI.
I think there's a line where AI enthusiasm becomes disdain for human expertise. If you can't be bothered to learn about licenses, what else are you just going to assume chatgpt can figure out for you?
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).
It is my understanding that one of the initial driving forces behind NeoVim was to allow for easier embedding, such as what you appear to be doing here. If this is true, why did you decide to go with traditional vim rather than NeoVim? Additionally, since nvim lets you choose between Lua or Vimscript for configuration/extension, and I personally find Lua far more intuitive than Vimscript...
> If this is true, why did you decide to go with traditional vim rather than NeoVim?
Answered here [1].
> I personally find Lua far more intuitive than Vimscript...
One of the biggest motivating factors for the rewrite of Oni was the limitations imposed by Vim/Neovim of a terminal grid of characters in the rendering layer: “Neovim treats the visible screen as a grid of cells” [2]. This precluded implementing CodeLens amongst other things [3].
I’m also a fan of Lua — I’ve written a substantial amount of Fennel — but given Oni’s goals, revamping Vim’s rendering layer is of higher importance than Lua support, particularly since the VSCode extension ecosystem is being relied upon anyway. Onivim is designed as more of a direct challenge to heavyweight IDEs than as a substitute for Vim. I already switch between Vim and VSCode depending on requirements, but it’d be great to have the best possible support for modal editing in VSCode.
“We skipped that and haven't implemented any vim backend at all ... so its the vim code base with terminal UI stuff stripped out, and an interface added for us to hook into it.”
You took out the most important part!
I don’t know about other people, but I became a vim user because I found myself configuring servers and needed to know a better text editor than nano.
Vim is also my primary code editor these days but portability is still a killer feature.
You are mis-interpreting what they did. They literally took vim, and built a ui around it. No re-implementation. It's Vim with a more modern frontend stack. You can go look at the libvim source and see it for yourself.
The point of this is to bring Vim into more modern workflows, not but "vim compat" but literally... vim.
Source: had some pull requests into libvim a while back to remove a lot of the various legacy compat features that don't make sense for libvim.
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.
I found that it was incredibly painstaking to build though, it's quite a barrier. I wanted to try it out a bit before buying, but it seemed to consume a considerable amount of disk space (>20GB), along with downloading tons of NPM dependencies and giving out weird errors during building.
Is there a particular reason why do you need such an amount of dependencies for building an editor?
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.
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...
reply