
Onivim 2: Lightweight, Modal Code Editor - teruakohatu
https://github.com/onivim/oni2
======
mkl
The licensing is a bit complicated. It is not really open source, until later,
when it is:

"∙ Free for non-commercial and educational use."

"∙ Commercial use requires the purchase of a license."

and then

"Because of the support we've received from open source communities, we've
decided to dual-license the code after 18 months - every commit, starting with
017c513, will be dual-licensed via the MIT License 18 months from that
commit's date to master."

~~~
bryphe
We decided to try a new approach to see how it works for funding - funding
open source projects is _hard_!

We wanted a model where, unlike completely proprietary licenses, the source
code could be available - and, worst case, if something happened to the
project - users could still have full access to it. And that all the work is
eventually available in general.

Our first OSS drops - from 18 months ago - are coming in next month (July
2nd), so that'll be exciting. It will be interesting to see how it works out.

~~~
GekkePrutser
I don't envy you... And as a software dev you don't want to be spending hours
on legal stuff either.

I do love the way you have the price so low.

~~~
bryphe
For sure... drafting EULAs, working with lawyers, setting up a sales pipeline
is not the fun stuff.

Would much rather work on bug fixes and features! Just a necessary evil to be
able to fund development. In an ideal world - could just write open source
software and not worry about paying bills.

------
ryannevius
I'm an advanced Vim user. I compile Onivim from source every couple of months
to see what progress is like. My biggest problem with Onivim is that some of
the design decisions reek of a design/development team that doesn't really
grok Vim. Even if it was feature complete, it would be a slower Vim with a
flashier UI and inconsistencies between the Onivim UX and Vim UX. As a
specific example, the way Onivim uses tabs/splits makes it a non-starter for
me.

I'm not really sure what the target customer/market is...Perhaps beginner Vim
users that want a better modal editing experience than the Neovim plugin for
VS Code provides, without having to sacrifice VS Code plugins? In any case,
props to the Onivim team for the progress/momentum behind the project.

~~~
richeyryan
I think you are pretty accurate in your assessment of the target market. The
way I'd phrase it is Sublime Text, with VS Code extensions and modal editing.
I don't imagine the target users want anything beyond the modes and text
handling, particularly the way Vim handles tabs and splits.

This is based on me personally. I use the vim plugin in VS Code. I wish it was
closer to real Vim keybindings, search etc but I want to keep the overall
handling of tabs and files.

So Onivim is very interesting to me, I have purchased it, because it looks
like it will give me the combination of speed, plugins and conventional
editing experience that I'm looking for.

~~~
WiiManic
(Dev on Oni2)

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.

------
rudolph9
I feel like a curmudgeon when say this but tools that make me leave my
terminal ultimately never sit well. It always feels so limiting when you hit
the point where you’re digging through the guts of some framework that
basically a web app packaged as a desktop app.

I see why people use it and maybe it not even a web app but I’m old enough to
know vim gets me everything I need and using some ide desktop app is going to
cost me more time in the long run.

For context, one of my biggest pet peeve is my dependence on desktop web
browser. I wish I could actually be productive using something lynx.

~~~
ravenide
I love vim and have never met someone who used it more fluently than me. Yet I
find it lacking. I can never get IDE features like code navigation and
completion to really work. I use YouCompleteMe like everyone else but it’s
just not as good as Jetbrains. It randomly stops working. Parameter hints
don’t really work. This is for C++, by the way. The JavaScript situation is
even worse.

My dream is also for vim to be the integrated, full-featured software package
you describe, but at the moment I find it falls short.

~~~
city41
I agree. I've been using vim for about a decade now. I love the editing
experience. I really dislike the "IDE" experience (plugins, file navigation,
etc).

I've been seriously considering writing a new vim clone in go and build what I
would consider the ultimate editor. Basically as if vim had been written
today.

~~~
bryphe
Onivim might not be for you :) But our project under the hood, libvim [1],
might be useful for you to start (if it's easy to create bindings from C in
Go).

There's a cool non-Onivim usage of it called Paravim [2] (and the same author
also used it for Vim-Cubed [3])

\- [1]
[https://github.com/onivim/libvim/blob/master/src/libvim.h](https://github.com/onivim/libvim/blob/master/src/libvim.h)

\- [2]
[https://github.com/paranim/paravim](https://github.com/paranim/paravim)

\- [3]
[https://github.com/oakes/vim_cubed](https://github.com/oakes/vim_cubed)

~~~
city41
Just to be clear, I was making my comment more in the context of vim than
Onivim. I maybe should have said that originally, my bad. I backed Onivim and
am keeping a close eye on it. Maybe I won't need to (try to) make my editor :)

~~~
bryphe
Ah, sorry I misread :) Thanks for supporting the project, really appreciate
it!

------
bryphe
Hi, I didn't expect to see this on HN! Thank you for posting it. I'm the
creator Onivim 2.

Still early days - and a lot of work - to realize our vision for this project
:) But I'll be around to answer questions.

------
GekkePrutser
I'd really love a proper IDE that works inside a terminal, I suppose this
won't either? What I'm looking for is something like VS Code but that does its
window drawing using curses. Not something as barebones as vim or emacs. VS
Code for terminal would really describe it well.

It would be really handy to be able to jump into a remote machine and work on
code that way without much lag or the need for heavy GUI stacks <3

~~~
the_angry_angel
neovim and coc.nvim might be close to what you're looking for, if you can live
with vim style motions, etc.

CoC basically takes VSCode addons and modifies them just enough to get them
working in conjunction with neovim.

~~~
GekkePrutser
Thanks to you also! I can learn vim (better), that's not a huge problem (and
it has some really useful shortcuts for stuff that take ages to do in a visual
editor). I'm just not looking forward to figuring it all out if you know what
I mean. Not trying to be critical but it does sound like a lot less
accessible.

Just to give some background: I'm not someone that spends hours in an IDE
every day. I'd just like something to easily install and that I can just jump
into, and that makes less frequently used features easy to find with a menu or
something.

Basically VS Code but then ideally in a terminal so that I can run it inside
tmux, and so it will work fine over a slower connection.

VS Code, while suboptimal IMO with its Electron implementation, does show the
way for an accessible IDE with great support for plugins. Even someone who
doesn't use it daily can figure it out. But it's GUI only :(

------
frizkie
Onivim 2 ticks a lot of boxes for me. I daily drive VSCode and I enjoy it, but
vim bindings are an absolute must, and the various extensions available always
leave a little to be desired, even if they do work pretty well.

Something built from the ground up with vim in mind, while still supporting
the mature extension ecosystem of VSCode is exciting. Glad to be able to
contribute further via Patreon[0] as well.

0: [https://www.patreon.com/onivim](https://www.patreon.com/onivim)

~~~
bryphe
Thank you frizkie - really appreciate it!

------
underdeserver
Looks really nice, and it's cool to see something like this implemented in
reason (OCaml really), but I don't see $35 worth of value compared to VSCode
or MacVIM.

~~~
skrebbel
If you're going to stare at your editor much of every workday, does the price
really matter that much? Even if it only makes you a _bit_ happier than
alternatives do, the price difference per hour used will be tiny.

I'd wager most software developers can shell out $35 on a whim.

~~~
bryphe
Right, we figured if it can save you just a few hours of configuration, it's
paid for itself.

------
gigatexal
Good for you guys and gals trying to find ways to pay yourselves.

------
dang
See also, if curious, from 2018:

[https://news.ycombinator.com/item?id=16995876](https://news.ycombinator.com/item?id=16995876)

[https://news.ycombinator.com/item?id=16673267](https://news.ycombinator.com/item?id=16673267)

~~~
WiiManic
And if its not obvious, the links are for Onivim1, rather than Oni2.

There is a somewhat out of date document on the motivation behind starting
Oni2 here:
[https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.m...](https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.md)

The big changes from Oni1 to Oni2:

\- 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.

------
yobert
I love these kinds of posts, if anything just because when I look at the
github page and then the language breakdown, I get to ask "What the heck is
reason?" and go find out!

~~~
bryphe
I'd highly recommend Jordan Walke's (creator of React) talk on the ideas
behind ReasonML: React to the Future [1].

I think it's so cool that you can take the ideas of ReactJS - functional
programming applied to UI - but then have a language (ReasonML [2]) that is
essentially purpose built for it, with OCaml [3] powering it under the hood -
a functional programming language that's been significantly invested in, both
in academia and industry. And to be able to take React-the-Idea, compile it
cross-platform, to native-code... and ship.

\- [1] Jordan Walke - React to the Future:
[https://www.youtube.com/watch?v=5fG_lyNuEAw](https://www.youtube.com/watch?v=5fG_lyNuEAw)

\- [2] [https://reasonml.github.io/](https://reasonml.github.io/)

\- [3] [https://ocaml.org/](https://ocaml.org/)

------
e_proxus
I’m still using Sublime Text because of its superior performance compared to
most other editors, and I’ve recently been super impressed by the
NeoVintageous plug-in [1].

It has a very complete feature parity with Vim and even implements many
popular Vim plug-ins such as surround, unimpaired and abolish.

[1]
[https://github.com/NeoVintageous/NeoVintageous](https://github.com/NeoVintageous/NeoVintageous)

------
jagged-chisel
> VSCode Plugin Support

Given this, and that there's at least one vim plugin for VSCode, is Onivim a
serious alternative? How does VSCode+vscodevim compare to Onivim?

~~~
vhakulinen
Oni was/is build completely on top of neovim and oni2 turned vim (not neovim)
into a library and builds on top of that.

I suppose the vscode plugin support is implemented in similar fashion as
coc[1] does it.

1:
[https://github.com/neoclide/coc.nvim](https://github.com/neoclide/coc.nvim)

~~~
bryphe
It's actually a bit different - VSCode has a 'front-end' process and a 'back-
end' process (the extension host).

The extension host is larger than just handling language services - it handles
additional functionality, like source control, menus, language configuration -
the full protocol is defined here:
[https://github.com/microsoft/vscode/blob/master/src/vs/workb...](https://github.com/microsoft/vscode/blob/master/src/vs/workbench/api/common/extHost.protocol.ts)

We aim to integrate with that back-end extension host process - in other
words, to support the `vscode` extension API surface, not just language
support.

Because of the ubiquity and popularity of VSCode - the extensions tend to have
significant investment and be of very high-quality, so we'd like to be able to
leverage that wholesale.

------
teruakohatu
Does anyone know why Oni ditched neovim, which they used in the original Oni
editor, and instead turned vim into a library (libvim) for Onivim2?

~~~
richeyryan
[https://github.com/onivim/libvim#why-is-libvim-based-on-
vim-...](https://github.com/onivim/libvim#why-is-libvim-based-on-vim-and-not-
neovim)

Guts of it is that Neovim didn't play nicely with their OCaml build and Vim
did. Rather than invest time in working through the problem, they went ahead
with Vim but remain open to supporting Neovim.

~~~
bryphe
> Rather than invest time in working through the problem

I don't think this is a fair characterization. We've made significant
investments in both Neovim and Vim, and carefully considered the trade-offs.

> Guts of it is that Neovim didn't play nicely with their OCaml build and Vim
> did

This was a smaller consideration - but more fundamentally, the model Neovim
uses for input - queuing it on an event loop and handling it asynchronously -
is at odds with what we required - to be able to process the input -> handle
updates synchronously.

There was a significant amount of incidental complexity in the architecture of
our V1 to fit that asynchronous model - we wanted to avoid that for V2, and we
switched to Vim because it fit that model.

~~~
richeyryan
Apologies, I didn't mean to insinuate that you were taking shortcuts or making
frivolous choices. My attempt to summarize obviously lost the nuance of the
decision.

I think the link summed it up well, near the end

> this was purely a constraint-based technical decision

------
bfrog
Is this another electron ide that takes minutes to copy paste in?

~~~
bryphe
We built a new UI framework to support development called Revery:
[https://github.com/revery-ui/revery](https://github.com/revery-ui/revery)

It's inspired by ReactJS, and has a similar API, but actually compiles to
native code (not javascript). So you have a React-like developer experience,
but with native perf.

~~~
ComputerGuru
That looks really nice - great job! There’s been a great amount of innovation
in GUI libraries in the past two years. What’s the ffi story here? Can it be
used as the frontend for a rust or C# application?

~~~
bryphe
Thanks ComputerGuru! :) Certainly, Revery is just putting together the
building blocks the ReasonML and OCaml communities have developed. Inspired by
ReactJS and Elm.

Revery supports the same FFI as OCaml [1] - C-style linking. I believe Rust
would be straightforward to integrate that way - I'm not sure about C#.

\- [1] [https://caml.inria.fr/pub/docs/manual-
ocaml/intfc.html](https://caml.inria.fr/pub/docs/manual-ocaml/intfc.html)

