8 ms·

Onivim 2: Lightweight, Modal Code Editor

123 points by teruakohatu 6y ago

jagged-chisel 6y ago
> 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 6y ago
  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 6y ago
    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/workbench/api/common/extHost.protocol.ts https://github.com/microsoft/vscode/blob/master/src/vs/workb... 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.
rudolph9 6y ago
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.
- bauerd 6y ago
  Fully agree. Primary reason I use emacs is because I can run it in my terminal (and I never got the hang of modal editing). All my readline shortcuts just work everywhere there, and copypasting from the tmux scrollback buffer is a breeze
  - lapinot 6y ago
    Ever tried https://github.com/jyp/boon https://github.com/jyp/boon? Modal editing for emacs, describing itself as ergonomic and respecting emacs conventions. Disclaimer: not using myself, i'm a happy http://kakoune.org/ http://kakoune.org/ user.
- ravenide 6y ago
  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.
  - typon 6y ago
    I find CoC to be much better than YouCompleteMe for both C++ and Python. Regardless, it's still not as good as Jetbrains. I don't know if it's a fundamental limitation of the underlying language Server (ccls) or CoC has issues with itself, but i experience random breakages in the autocompletion all the time too.
  - w-j-w 6y ago
    You are looking for CoC. Some vimmers resist it because of the node.js requirement, but it's totally worth it.
  - mtts 6y ago
    > Yet I find it lacking. I can never get IDE features like code navigation and completion to really work. Same here. In the end I just gave up and installed Emacs with vim key bindings (evil mode). Took a while to set things up, though, albeit not so much the vim bits, which were fine, but the IDE features. Vim is fine as a framework for text editing but as an application it's a bit lacking.
underdeserver 6y ago
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 6y ago
  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.
  - GekkePrutser 6y ago
    Yeah $35 is nothing really. If I end up using it I'd gladly pay that to support them, even if I don't use it commercially. Look at what something like Visual Studio or IntelliJ cost for a commercial license :D This is nothing.
  - bryphe 6y ago
    Right, we figured if it can save you just a few hours of configuration, it's paid for itself.
mkl 6y ago
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."
- O_H_E 6y ago
  It is really intriguing to see how this works for them. Making money from normal open source projects is really hard. I am really hoping to see some innovation in this sector (FOSS+Economical sustainability) sooner rather than later.
  - Cthulhu_ 6y ago
    The other post about Github sponsorship works; it means the code remains open source and the application free to use, whilst the developers get paid for contributing to it. That said, I think it's mainly down to companies that use the open source software to start paying for it. All companies that use open source software - and be fair, this is pretty much all software companies - should reserve some budget to sponsor and donate to open source project and developers. Second, there's a lot of open source projects whose developers are paid for by a company, e.g. Linux, Chromium, etc. That code is still open source and free, AND the developers get paid.
  - mkl 6y ago
    I think once a program is established and has all its main features in there and polished, the 18 month old version may not be very different than the current version for practical purposes. I.e. if this model works, it may only work well while they're getting started and adding new useful primary features.
    - dmos62 6y ago
      Even in vim new features often have me check which version I'm running. I'd say that when you start using more than the basic features then updates start becoming interesting.
teruakohatu 6y ago
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 6y ago
  https://github.com/onivim/libvim#why-is-libvim-based-on-vim-and-not-neovim https://github.com/onivim/libvim#why-is-libvim-based-on-vim-... 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 6y ago
    > 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 6y ago
      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 6y ago
Is this another electron ide that takes minutes to copy paste in?
- ryannevius 6y ago
  No, it's using Reason/Revery.
- bryphe 6y ago
  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 6y ago
    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 6y ago
      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
ryannevius 6y ago
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 6y ago
  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 6y ago
    (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.
- bryphe 6y ago
  Thanks for checking out the project! This is one of the biggest pieces feedback we've received both the tabs / splits in particular [1], and the more general issue of broader Vim compatibility [2]. We actually use a forked Vim implementation under the hood (libvim [3]) - as the modal-editing engine. So Onivim, in theory, _could_ support everything. The main issue is 'wiring up' features from libvim to our front-end. We'll be focusing on this in our next milestone (July-Sep) - with the high level goals of supporting more traditional Vim workflows, Vim tab support, along with VimL plugin support and init.vim/vimrc compatibility. Ultimately it's a prioritization problem - so having feedback like yours is really helpful, so that we can focus on the right priorities for that work. - [1] https://github.com/onivim/oni2/issues/592 https://github.com/onivim/oni2/issues/592 - [2] https://github.com/onivim/oni2/issues/1551 https://github.com/onivim/oni2/issues/1551 - [3] https://github.com/onivim/libvim https://github.com/onivim/libvim
GekkePrutser 6y ago
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 6y ago
  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 6y ago
    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 :(
- acupofnope 6y ago
  There are Vim plugins that enable you to do just that. I do have a few which allows me to run a terminal command, navigate directories, manage git repo...etc all without leaving Vim
  - GekkePrutser 6y ago
bryphe 6y ago
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.
yobert 6y ago
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 6y ago
  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 6y ago
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
frizkie 6y ago
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 6y ago
  Thank you frizkie - really appreciate it!
gigatexal 6y ago
Good for you guys and gals trying to find ways to pay yourselves.
dang 6y ago
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 6y ago
  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.md https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.m... 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.

123 points by teruakohatu 6y ago

> 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 6y ago
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 6y ago
  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/workbench/api/common/extHost.protocol.ts https://github.com/microsoft/vscode/blob/master/src/vs/workb... 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.

rudolph9 6y ago

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.

bauerd 6y ago
Fully agree. Primary reason I use emacs is because I can run it in my terminal (and I never got the hang of modal editing). All my readline shortcuts just work everywhere there, and copypasting from the tmux scrollback buffer is a breeze
- lapinot 6y ago
  Ever tried https://github.com/jyp/boon https://github.com/jyp/boon? Modal editing for emacs, describing itself as ergonomic and respecting emacs conventions. Disclaimer: not using myself, i'm a happy http://kakoune.org/ http://kakoune.org/ user.
ravenide 6y ago
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.
- typon 6y ago
  I find CoC to be much better than YouCompleteMe for both C++ and Python. Regardless, it's still not as good as Jetbrains. I don't know if it's a fundamental limitation of the underlying language Server (ccls) or CoC has issues with itself, but i experience random breakages in the autocompletion all the time too.
- w-j-w 6y ago
  You are looking for CoC. Some vimmers resist it because of the node.js requirement, but it's totally worth it.
- mtts 6y ago
  > Yet I find it lacking. I can never get IDE features like code navigation and completion to really work. Same here. In the end I just gave up and installed Emacs with vim key bindings (evil mode). Took a while to set things up, though, albeit not so much the vim bits, which were fine, but the IDE features. Vim is fine as a framework for text editing but as an application it's a bit lacking.

underdeserver 6y ago

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 6y ago
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.
- GekkePrutser 6y ago
  Yeah $35 is nothing really. If I end up using it I'd gladly pay that to support them, even if I don't use it commercially. Look at what something like Visual Studio or IntelliJ cost for a commercial license :D This is nothing.
- bryphe 6y ago
  Right, we figured if it can save you just a few hours of configuration, it's paid for itself.

mkl 6y ago

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

O_H_E 6y ago
It is really intriguing to see how this works for them. Making money from normal open source projects is really hard. I am really hoping to see some innovation in this sector (FOSS+Economical sustainability) sooner rather than later.
- Cthulhu_ 6y ago
  The other post about Github sponsorship works; it means the code remains open source and the application free to use, whilst the developers get paid for contributing to it. That said, I think it's mainly down to companies that use the open source software to start paying for it. All companies that use open source software - and be fair, this is pretty much all software companies - should reserve some budget to sponsor and donate to open source project and developers. Second, there's a lot of open source projects whose developers are paid for by a company, e.g. Linux, Chromium, etc. That code is still open source and free, AND the developers get paid.
- mkl 6y ago
  I think once a program is established and has all its main features in there and polished, the 18 month old version may not be very different than the current version for practical purposes. I.e. if this model works, it may only work well while they're getting started and adding new useful primary features.
  - dmos62 6y ago
    Even in vim new features often have me check which version I'm running. I'd say that when you start using more than the basic features then updates start becoming interesting.

teruakohatu 6y ago

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 6y ago
https://github.com/onivim/libvim#why-is-libvim-based-on-vim-and-not-neovim https://github.com/onivim/libvim#why-is-libvim-based-on-vim-... 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 6y ago
  > 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 6y ago
    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 6y ago

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

ryannevius 6y ago
No, it's using Reason/Revery.
bryphe 6y ago
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 6y ago
  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 6y ago
    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

ryannevius 6y ago

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 6y ago
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 6y ago
  (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.
bryphe 6y ago
Thanks for checking out the project! This is one of the biggest pieces feedback we've received both the tabs / splits in particular [1], and the more general issue of broader Vim compatibility [2]. We actually use a forked Vim implementation under the hood (libvim [3]) - as the modal-editing engine. So Onivim, in theory, _could_ support everything. The main issue is 'wiring up' features from libvim to our front-end. We'll be focusing on this in our next milestone (July-Sep) - with the high level goals of supporting more traditional Vim workflows, Vim tab support, along with VimL plugin support and init.vim/vimrc compatibility. Ultimately it's a prioritization problem - so having feedback like yours is really helpful, so that we can focus on the right priorities for that work. - [1] https://github.com/onivim/oni2/issues/592 https://github.com/onivim/oni2/issues/592 - [2] https://github.com/onivim/oni2/issues/1551 https://github.com/onivim/oni2/issues/1551 - [3] https://github.com/onivim/libvim https://github.com/onivim/libvim

GekkePrutser 6y ago

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 6y ago
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 6y ago
  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 :(
acupofnope 6y ago
There are Vim plugins that enable you to do just that. I do have a few which allows me to run a terminal command, navigate directories, manage git repo...etc all without leaving Vim
- GekkePrutser 6y ago

bryphe 6y ago

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.

yobert 6y ago

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 6y ago
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 6y ago

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

frizkie 6y ago

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 6y ago
Thank you frizkie - really appreciate it!

gigatexal 6y ago

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

dang 6y ago

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 6y ago
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.md https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.m... 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.