Oni – Modern Modal Editing
onivim.io
onivim.io
I find myself using the mouse all the time, and I don't understand this obsession with mouse-less text editing. The mouse lets me perform selections, and with some key-combos in sublime text sets me up for multiple cursor editing very nicely, in ways that would be much much more complex if I were trying to do them in vim.
I've always wanted to try out Acme, a mouse-first editor from plan nine, with all of this obsession with cutting the mouse out entirely, it feels like there is space for an editor to really consider what the mouse can be used for.
For your information: the issue with mouse-laden text editing is that you need two hands on the keyboard to type, so you are repeatedly moving a hand between the keyboard and the mouse. This takes time: in my experience enough time that it's often faster for me to use keyboard navigation _anyways_. Plus the constant wrist motion can be bad for RSI.
That said, if you can edit more efficiently with the mouse, and your wrists don't hurt, then go for it.
I currently use kakoune which is probably the closest thing to that idea in a production ready editor, only the 'plumber' is done with shell commands, which can send variables back to running instances, so it's more DIY than plan9 plumbing.
It gets fatiguating after a while. If you are doing lots of selection, moving around, insertions, etc it accumulates.
I only use vim for any text editing. I also use a vim plugin to navigate chrome. And several other keyboard shortcuts to navigate macos. The accumulation really helped.
(For the record, I currently use Macvim but am deeply interested in Oni and other projects. I've been a vim user for many years now and consider myself reasonably proficient, although, you know, it's vim after all, there's always more to learn).
I recently installed a plugin that lets me open MacVim with a shortcut (https://github.com/cknadler/vim-anywhere). Everytime I use it I remember why I avoid the GUI.
But I really don't understand the "constantly opening and closing my editor" thing. I'm usually working on one or two projects at a time at most, and just keep a window open to that project. This is pretty much how most people work. Why doesn't that work well?
I'm genuinely asking btw. I'm not sure why loving vim is so correlated with working with your editor in such an unstandard way. (I mean, I'd guess it's the opposite - people like me come to vim for reasons having nothing to do with that, and try to use it like our old IDEs, whereas people who started off wanting to do everything in the terminal look for a solution and find that vim fits them. But that's just a guess).
I'm sorry, I didn't mean to offend. As I said - I'm genuinely curious as to what you feel makes this method better. I wouldn't be wasting my time asking if I didn't think there was a chance I might learn something that would make me change the way I work - that's how I picked up vim in the first place, not to mention every other improvement I've ever made in my life.
This is a subject that has been hashed to death online, especially in Vim vs Emacs discussions. Emacs behaves more like an IDE, as an environment rather than a tool. Vim is further along the tool side of the spectrum (though I sense Plan 9's Acme is even further along; Vim is actually pretty moderate, believe it or not). Gvim tries to bisect the difference, but I find it to be the worst of both worlds: not as nice an experience as say Idea or PyCharm, but also encouraging "bad habits" from the terminal point of view, such as using the mouse. Or navigating where you are in the system from within the editor rather than the shell.
I actually do use multiple windows and Alt-tab between them. It's just that most of them are terminal/shell/tmux windows. I do use other apps too (like a web browser). But for text processing and navigation the shell is what I like best.
Anecdotally Vim users seem more sensitive to even small latencies, and GUIs invariably seem to introduce lag. Though I'm finding that I'm more tolerant of lag in my non-shell windows. Using VimAnywhere has made that clear because it causes the "universes to collide".
This whole question is actually not that important, in my opinion. You were right above that it's mostly about what way you start out in. If you're reasonably effective with one set of tools, to try to switch is to bait big to catch small. There's far better uses of your time out there. Perhaps the only thing to learn is that there are many ways to skin the cat. There, now move on.
What exactly don't you understand about it? For me it's the single most frequently used environment, I can do more things and do them faster than in any other way. What is there about it not to understand?
Then, I don't mind alt-tabbing either. I do mind, however, the amount of it. I have multiple terminals open and I operate at the limit of my abilities to manage them. With a separate GUI window, I would either have one more window to switch through (and thus I would be over my limit) or have one terminal less to execute commands.
> But I really don't understand the "constantly opening and closing my editor" thing.
A workflow thing. I don't understand people running GUI for version control, or GUI for simply opening a file in a directory tree, yet people do that all the time.
But it's also nice to pop open a new vim in any old directory to deal with one or two edits that don't belong to a real project. I do this all the time when dealing with docker or Dev ops type tasks that don't require managing a lot of code.
I can chain cli calls together to create powerful workflows.
I have highly scriptable workspace management with tmux + vim.
I don't have to wait for web pages to load to run commands, I can just do the thing in the same place I do everything else.
Many people don't gain that much from the terminal but if you are a power user it makes your life great.
I don't like GUIs, they take too much space, are always trying to sell me something, present information in an inferior way ( I like my dark, cool colored termina l color palette ), and I can't script repetitive tasks.
most cli tools have the same conventions so learning new tools has way less overhead.
Just a few reasons.
1) Because when I started programming, that's what I used. I'm comfortable in it because I'm comfortable in it :-) I'm pretty sure that's most of the issue to be honest. When I've asked people what they like most about their graphical IDEs, I've come away with the impression that the same thing governs the majority of their preference: it's what they are used to.
2) My vision is poor. I use a 22 point font. The layout of most GUI programs tends to leave no room for editing if I use the same kind font size (I also have poor peripheral vision, so I use a 13" display which fits comfortably in the section of space that I can see). Things like menu bars, file trees, object trees, test panels, etc, etc are more than useless to me. If I close all of them down, I'm left with exactly what I have in my terminal window.
3) I don't like to use a mouse. I use a tiling window manager. Often I work in tmux (for which I've set up key bindings exactly the same as my tiling window manager) and I might not even have X running (I probably have the most tricked out linux console of anybody I've ever heard of). I used to have a trackball, but I've given it up and now work exclusively with a laptop with a track pad because I've gotten myself to the point where I almost never have to use it.
4) Performance. I have 8 gigs of memory in this laptop. I have swap turned off. I almost never use more than 2 gigs at a time (sometimes I have a VM which has 2 gigs allocated to it, so then my memory usage creeps up to 4 gigs). Lots of memory for file buffers :-) People are always amazed at how responsive my machine is, despite being a 3 year old i5 mobile processor with 8 gigs of memory. IDE's are bloatware for me. I won't use the extra features anyway.
Most of this is personal, but that's what you get for preferences. A few people I've worked with have seen my setup and have gone a similar way. I know a couple of people who also live in Emacs -- they never leave Emacs if they can help it because everything is completely integrated in a way that you just can't do in other environments (that I've seen, anyway).
In the late 90's I worked on Windows stuff and my employer forced me to use Visual Studio (yeah, employers actually pulled crap like that in the 90's). I eventually modified it to the point where I liked it quite a lot. I'm sure I could do the same with most IDEs out there now, but there's no point. The terminal gives me everything I want at minimal resource overhead.
Yeah, it could be done more efficiently without a full blown browser engine, everyone knows that. But honestly, who doesn't already get that? It hasn't stopped me from using VS Code regularly, which is already more performant than IntelliJ imo, an app that doesn't use Electron.
Almost everything that can be said on this front has been said. Does it really need to be the top 3 comments every time?
I think the hope is if we keep going "Electron isn't a great idea, there are a lot of drawbacks, please stop", people will actually stop.
I've been using Oni for the last few weeks as my daily driver (I liked it so much I signed up as a monthly sponsor), and here's my take on it:
It's a fairly new project, but it's under _very_ active development. There's an excellent community building around it and I think we will be seeing some really great progress over the next year. That said, it isn't anywhere close to feature parity with vscode, but the value proposition is: neovim, with vscode compatible snippets and typescript-language-server-driven autocomplete (also works with vanilla JS) out of the box. AFAIK it works with any language language server with a few lines of configuration. I have tried several times to get You Complete Me working to my satisfaction and never quite got there despite spending several weekends working on it. Oni just works.
The bonus value proposition is: since it is a GUI wrapper around neovim, you get to retain all of the muscle memory you have built up in your years of using vim, but potentially also get many of the goodies that a graphical IDE like vscode provides. I have tried the vscode vim extensions, and they are really impressive, but they are still limited by the vscode extension api and at the end of the day it's not a real vim. For me, it was just not-vimish enough to constantly interrupt my flow; I believe the original inspiration for Oni was the creator's frustrations with vscode vim extensions.
I have been digging into the development process and I've been _really_ impressed with how brilliant and industrious the main contributors are; features are getting added at a breakneck pace. A few things that are in the works: real-time browser pane with auto-refresh (I just tried out the browser feature and it works like it's just another vim buffer... pretty awesome stuff!), markdown preview, a gamified tutor mode for newbies, and a webgl renderer that is about 10x faster in benchmarks than the canvas renderer.
I'm not trying to prove your point by making the insufferable comment that you hate and already expect, so please understand I am genuinely interested:
Why would, or why should, a person interested in creating a cross platform desktop app, choose electron?
If it's just to use their favorite web components to design with, is that really a good enough reason? When GTK and Qt both provide js api capabilities, what else is there to gain?
Please understand, I'm not a web developer, I'm not familiar with most of it, but just the thought of 100+MB overhead for an app is completely unacceptable to me. But again, the benefit of using web tech is lost on me.
1. It enables a large swatch of people that have never done desktop development (which has a learning curve that is hard to climb if you aren't paid to do it) to build cool stuff and ship it. Without Electron, we'd be left with nothing. If nothing is truly better than something with Electron, then this won't be a compelling point. However I'd rather have stuff that I ignore than to not have stuff.
2. Performance in electron can be decent. It isn't always because of bloat and poor implementation, but that can be true of native apps as well (especially java-based ones). The download size is laughable, but hard drives are reasonably sized these days so this is less of a pragmatic concern, and more of an ideological purity concern.
3. The modern paradigm that React brings to the table can genuinely be a better dev experience than the traditional frameworks. The benefits of "always re-render" would have fixed numerous bugs that I dealt with in UI land regarding state and dealing with changing state. Developer happiness is worth a lot when the project is open-source, unfunded, and done by someone with passion (which is how almost all open source starts).
4. I think it's temporary. There's projects like Proton that are already looking at how to get the best of React/JS on the desktop without the bloat of shipping a web browser with your app. The future looks bright.
NOTE for people devving on electron: Please be more conscious of memory usage and potential memory leaks. Desktop apps are often long-running and you've got to pay attention to resource usage and the memory leak traps that can cause your app to gobble up insane amounts of memory (cough slack cough)
I'm concerned that someday html might be the standard for gui system markups, that could go wrong easily.
Part of my perspective on this, maybe yours as well, is the amount of projects in electron that just didn't need to exist in the first place. Guys writing email clients, for example. Nobody is going to use something like that. Casual users will prefer the browser and power users need mega-apps like Thunderbird to be productive enough.
I've been hoping Elm guy would try and bring Elm to Qt or OpenGL or something like that. I think desktop apps have a lot to learn from FRP, which is prevalent in web tech, or at least more so than it has been in the past.
It almost reminds me of Emacs, ya know? Everything and the kitchen sink, and the plumber, and his truck, and the Home Depot. Unnecessary!
Anyways thanks for your comments. Your experience is helpful!
Something like Elm coming to Qt would be great!
> When GTK and Qt both provide js api capabilities, what else is there to gain?
It's the HTML5. How would you write an xplat editor with GTK or QT? The obvious answer is to use Scintilla and after some Googling surrounding getting that right, you're successful! Now you want to start innovating the editor, with both the speed and bravery that the VSCode team do. Now you have problems.
As much as I despise HTML5, it does provide a canvas that behaves consistently across platforms (so long as your browser is consistent, which Electron is). I can't see why you'd use it for a music app or so forth, but rendering a text editor is a surprisingly difficult task - it does present genuine benefit in this field.
You could use OpenGL or Vulkan, but then you'd spend your life writing the UI framework and wouldn't have the xplat layer that NodeJS offers.
Text editors are a great example, they're very difficult to get right.
I wonder why more desktop GUI platforms aren't equipped with something similar to html5->native markup.
Thanks for your comment, that clears up the question of appeal for me a bit. I can see how much frustration is saved in a project like vscode by using electron.
I'm personally a bigger fan of XAML (done right, with MVVM) for that purpose, but it's unrealistic because XAML is dead. So ultimately I agree, there should be a browser of sorts for highly trusted apps. Electron is a runtime, it shouldn't be bundled with every app that uses it.
GTK claims to be cross platform, but the windows support is (at least was), awful. Lots of special casing required. Also hi dpi screens never worked right. Also just getting tge dev environment configured on mac, windows and linux was a multi day undertakung and required weird dodgy mingw gcc builds.
With electron, the multi platform is taken seriously. It just works. Also, because electron doesnt try to look like each OS's default toolkit, your app looks the same in all 3 major OSes, so you dont need piles of os specific GUI fine tuning code.
That's a significant selling point actually. When I did Qt and also Swing, this was something that got me often. Making something look just right with polish gets to be quite difficult without having tons of platform specific code and logic.
So it's mostly Qt vs Electron. Having to compile different binaries for every Linux distro and version makes Qt a non-starter for most. And if you're going to compile it statically to try to avoid that dynamic linking nightmare, you just added more bloat to your download than Electron.
Qt is hardly a popular toolkit for Windows and macOS apps.
And if I use Electron and React, I get to add native-ish mobile apps for little extra work by using React Native there.
Oni maintainer here! I agree - I get stressed out sometimes when this gets posted to HN for that reason ;)
I'll piggyback here because this is near the top, but I'll give a couple quick reasons why Electron was chosen for this project:
- Development speed As mentioned in another comment, the React ecosystem has some excellent development tools around hot-reloading / live-reloading. I never found this sort of 'live-reload' workflow in any of the C/C++ toolchains I've used. (Would be interested if that has changed!)
For a very small team, this is an important consideration! It's the difference between Oni existing as an Electron app vs. not existing at all.
- Developers Oni is an open source project, and I open-sourced it because I wanted help building it (and I've been fortunate to work with some amazing contributors [1]). When you look at the last StackOverflow Developer Survey [2], web tech is overwhelmingly at the top - if I want help, I should pick the tech stack that has the broadest appeal.
Every editor is an exercise in trade-offs, and of course Electron brings trade-offs of its own. Oni is an experiment in a different (not necessarily better, because that's subjective and relative to each person's workflow) set of trade-offs than other editors - an attempt to bring together the "modern" functionality of editors like Code/Atom with Vim. It resonates with some people, but it's not going to be for everyone, and that's OK.
Even if you don't use Oni or agree with the tech stack, these sorts of experiments are important, because if new ideas or workflows work well... they can find their way into your editor of choice, too.
One other note - I focused a lot on Electron, but the project wouldn't be here without neovim, either! They've done excellent work, and there is quite a variety of front-ends - so even if Oni isn't your thing, I'd encourage to check out that project as well as some of the front-ends for it [3].
[1] - https://github.com/onivim/oni/graphs/contributors
[2] - https://insights.stackoverflow.com/survey/2018/#technology
[3] - https://github.com/neovim/neovim/wiki/Related-projects
It seems the title comes from the submitter here, rather than the web page.
I've looked at this, and as a VSCode user, it is not at all a useful replacement, it's barely usable for me. Also VSCode has a lots of useful plugins, which aren't support here.
I'm sure if I learnt all the vim shortcuts it would be great but then I'm using VSCode because I don't like vim.
Oni was just way too slow and i couldn't use the plugins i needed from my previous vim setup. I switched to VSCode and now I get best of both worlds!
Whether or not Oni provides additional utility over a standard (neo)vim in a terminal is probably dependent on personal preference. There is also definitely a cost to the use of Electron, I typically have 4 or 5 windows running at a time, one for each project I work on, and it uses about a GB of RAM in total, so if you're on a memory-tight system you may not want to stick with terminal vim.
I use "oni.useDefaultConfig": false and "oni.loadInitVim": true and use it basically the same way I use terminal vim, but with language server autocomplete thrown in for free.
CLARIFICATION: For me the whole point of learning vim was that it's lightweight and ubiquitous. Stuff like this is 0 out of 2 on that front.
But yeah, that is why even I as Emacs user always bothered to at least know my way around vi, usually Emacs is most likely not installed.
Let's be honest: out of 10000000000's of SSH connections in a given 24 hours span, how many are to a "classical proprietary UNIX server"? 0.0001% maybe ? Is it really a use case worth optimizing for ? They should be treated as applicances, not as general-purpose computers.
That said, if you're doing almost all your work from your local machine, these editors probably serve a valuable purpose still.
Lol, this is most people, and also the target audience of this application. Note that it doesn't claim to be a VIM replacement, just a modal editor for the desktop that's based on it.
As long as the Vim emulation is good you are still using the same “skills”.
In the case of the OP it’s a frontend to neovim even, so it’s not even just a partial emulation, it’s the real deal.
That being said I tried Oni a few weeks ago because I thought it would bring me something but I found no immediate advantage so I didn’t bother to keep using it.
There's definitely an argument to be made that Oni may not add much over running vim in a terminal, especially given the increased resource requirements inherent to electron, and I'd certainly like to see a high performance cross platform neovim gui that doesn't use electron, but I think Oni at least delivers a very useful experience on its own by building on top of all the work already invested into vim.
I'm glad everyone likes vim as an editing style. I do to and would prefer to use vim, however I was able to get VS Code configured with plugins how I want to work in a matter of minutes, as opposed to wasting days upon days (over my life probably a solid month) trying to get a sane vim config that works with my languages and tools.
Anecdote: be on Windows. Need text editor to open 100MB file. Notepad sucks. Wordpad actually loads the file, but I just can't. Think about getting Notepad++. Decide to try out Atom because the UX looks nice. It can't load the file; have to kill the process. Install Emacs. Just works.
These things are cool for your portfolio, but they are less effective than 40 year old alternatives.
Product might not be for you.