Has the dev stopped?

[nirgivon]

Is the project dead?

:-\

[bpingris]

yes it has stopped:
#3811 (comment)

[nirgivon]

:-(

[v3ss0n]

Oh well , i expected since they rewrote it into a very niche esoteric language ...
With that very hard to find contributor , let alone maintainer ..

[mawkler]

Rewrite it in Rust and call it Onivim 3?

Third time's the charm

[Giancarlos]

Honestly, if they rewrote it in OCaml instead, that would be fine by me. I think a small part of what makes this a lot of work is the fact the maintainers built their own UI stack, so as they maintain this magnificent project, they also update the UI stack. The other issue is the underlying language behind Revery has an unknown maintenance state due to the churn of what I call the JS ecosystem (since it is coded in ReasonML and that looks unmaintained as well).

At least OCaml would hit some of what ReasonML supported, and be somewhat similar to the capabilities of Reason (like a native UI).

I also wouldn't care if they rewrote it in Rust. I also would be happy if the maintainer setup a Patreon account or whatever so we can all chip in. I see a lot of promise in Oni 2, and I'd be okay paying more for a license (I've wasted more on Sublime) just to see where it can go. Neovim is a gem lacking a powerful UI, and Oni 2 is barely touching the surface of what it can be, and it is insanely close.

[v3ss0n]

Rewrite it in Rust and call it Onivim 3?

Third time's the charm

DO IT! :D

fact the maintainers built their own UI stack, so as they maintain this magnificent project, they also update the UI stack.

bad decisions. I had seen many bad decisions killing great projects in opensource world.

[Giancarlos]

Hey @bryphe or @glennsl can you share some insight here? It's a shame because this project is highly promising otherwise. It's rare to get me excited about a new text editor. :)

[v3ss0n]

check neovide , it is not over-engineered and it just work with all kind of neovim distro. It is written in rust , and very high perofrmance : https://neovide.dev/

also https://github.com/equalsraf/neovim-qt

more active development.

[glennsl]

Hey @bryphe or @glennsl can you share some insight here?

Insight into what?

Technically, I can at least tell you that I don't think that the custom UI stack was the problem. While it certainly wasn't perfect and had an unrealized potential that could have been revolutionary, it did what it needed to do quite well. And having also worked on a UI project in Rust, I am quite confident that its order of magnitude higher compilation times, poorer abstractions and the constant cognitive overhead of having to deal with manual memory management would have made the project move significantly slower.

I wouldn't have minded if it was done in OCaml either, but I don't think it would make much if a productivity difference from using ReasonML. Keeping it up to date really isn't that much work, it's just a syntax layer after all, and it's not like you'd lose anything if it didn't get updated. You'd just lose out on the shiny new stuff. On the other hand it has a much more approachable syntax, and is a much easier language to learn than Rust, coming from most other mainstream languages.

I think any productivity problem came mostly from architectural issues, and handling the intersection between a functional architecture and vim's imperative architecture. Those are issue that will rear their head in pretty much any project, regardless of stack choice. I am still quite impressed at how fast the project moved, really, especially given all the different pieces involved and the innovative stack that was co-developed to support it. I really don't think a lack of productivity was the problem, nor do I think that recruiting more volunteers would have made much of a difference. There just wasn't enough income to sustain development with at least a single core developer. And with a project of this scope you really do need that core.

check neovide , it is not over-engineered and it just work with all kind of neovim distro. It is written in rust , and very high perofrmance

It doesn't have the vscode extension host integration though, which is like half the selling point of Onivim...

FWIW, I'm using Doom Emacs now. Wouldn't say it's high performance, or flashy, but it's very productive, very low maintenance, very easy to configure, and indistinguishable from vim, at least for my use. And it has a ton more productivity-boosting features than either vim or vscode (magit, org-mode, rgrep+wgrep, tramp and rest-client to name a few).

[v3ss0n]

Technically, I can at least tell you that I don't think that the custom UI stack was the problem. While it certainly wasn't perfect and had an unrealized potential of being quite revolutionary, it did what it needed to do quite well. And having also worked on a UI project in Rust, I am quite confident that its order of magnitude higher compilation times, poorer abstractions and the constant cognitive overhead of having to deal with manual memory management would have made the project move significantly slower.

Rewrite it in Rust and call it Onivim 3?

I am sure that one is a joke

[glennsl]

I hope so, but I continue to be baffled by how many projects choose to use Rust despite how bad of a fit it is. Especially UI projects, where fast iteration is key and the event-based nature of UIs really benefit from garbage collection.

[v3ss0n]

I agree , many of the Rust UI frameworks targets and complies to WASM and resulting WASM for UI is horrible.. not fast , sluggish

[Giancarlos]

It doesn't have the vscode extension host integration though, which is like half the selling point of Onivim...

This is the part that blew me away the most, a native runtime running the VSCode extension host. Thank you for providing insight into the questions, I agree, I don't think the language matters as much, I wrote that thinking purely of the confines of what Onivim was.