Neovide – A simple, no-nonsense, cross-platform GUI for Neovim

How do you handle multiple projects at the same time, with a tiling window manager? The nice thing about the terminal is the possibility of having layouts, tabs and so on. Or using tmux/zellij with a terminal that doesn't support these more advanced features.

I've actually found the animations helpful even thought was initially skeptical: Because it visualises the vim motions it makes it much clearer what is happening. Especially if you make a mistake you'll see it much more clearly what it actually did. Also when making longer cursor jumps it is easier to see where it went.

I'm sure they will help a lot also when learning Vim for the first time.

But the be fair, the default animations are bit much but they can be toned down.

I just tested again after a while.

Input latency is very notably worse than in the terminal, at least on Linux + sway. (alacritty or kitty)

I actually liked those animations and enabled a similar functionality in VSCode:

        "editor.cursorSmoothCaretAnimation": "on",

As an alternative, try foot. I love that terminal, it just works.

Friend... don't try to "switch". Just use multiple tools at the same time. I personally use all: Neovim (great writing/editing experimence, LSP+Treesitter+fzf allow you to get really far), Emacs (for Magit), VS Code (if Neovim or Emacs breaks I can still edit the code ;)) and WebStorm to run tests using nice and rich UI. Don't try to limit yourself artficially.

I suggest you try something like LunarVim[1] or NvChad[2] for a ready-to use IDE-like neovim configuration.

I had the same problem with configuring (neo)vim, it's simply too much work to get a reasonable IDE experience. Using an already well tested and documented configuration helped me to make the switch.

[1] https://www.lunarvim.org/

[2] https://nvchad.com/

I think if you're happy with the experience that the IDEs you mentioned provide you, then there is very little reason to switch.

Being familiar with vi keybindings can be useful if you ever find yourself on a minimal system with no other editors available, but the subset of knowledge you need in that situation would be much smaller than if you wanted to use Neovim as your primary development environment. I think Emacs/Vim/Neovim and the like are better suited to users who actually enjoy the process of configuring stuff like LSPs and code completions in a way that's fine-tuned to their personal preferences and works the same across all programming languages.

If you are happy and productive with your current editor(s), no, you don’t need to spend valuable time picking up and configuring another one. Save the effort for when you actually need it.

Despite what others may say to convince you otherwise, this is the only correct answer ;)

I feel you, I feel the same. I just like modal editing too much. Even though I have to remap CapsLock to Escape to make that usable.

I feel naked without those commands at my fingertips. It's not even about speed, without it it's like... it's like woodworking with a table knife

If I were to take up modal editing now, I'd go for Helix. It's a better editing paradigm (Kakoune inspired) and it aims at just working out of the box.

I finally opted for Lunarvim but I believe all those Neovim distributions are great

I'm the same way. I've tried like a half dozen times over the years to "get into" vim. It seems like the perfect thing for me. I used to love wasting time ricing my Arch install. But you know what happens? I get 3 hours into setting it up and realize I am only marginally closer to what I already have with VS Code. And in VS Code if I want more language support or some fancy new feature, it's like 3 clicks and it's just working immediately.

kickstart.nvim [1] is the best way to get started if you want to understand how things are configured rather than using someone else's config.

It's a single file and you can pretty easily use it as a starting point for your own config.

And it comes with the which-key.nvim [2] plugin that helps you learn vim motions.

[1]: https://github.com/nvim-lua/kickstart.nvim

[2]: https://github.com/folke/which-key.nvim

I would recommend the helix editor[1].

You won't get the deep magic of emacs, or the benefit of learning vi key bindings (sadly there's not yet a helix mode for gnu readline) - but you get a great modal editing experience, good defaults and great discoverability.

I moved from vim/neovim a while back - and now I find vi/vim verb-object (d[delete]w[ord]) yanky compared hx visual select/object-verb (wd).

I've been using vim for some 15-20 years prior.

[1] https://helix-editor.com/

While I can't say this is true for vim, in Emacs, I found that the customizability helps for a lot of different programing tasks. I run my terminals in Emacs and they are associated with my projects. Magit (the Emacs git package) helps me do complex rebases with diffs alongside creating branches and everything else you might do in git (even the reflog when things get rough). There is event a handy rest-mode that lets me write and save HTTP sessions. I connect to my database in buffer as well. What makes all this so handy is that I can move the buffers around to compare things side-by-side, use a single large buffer, etc. While VS Code has splits and terminals, I found that in Emacs I can access everything from my keyboard and now that I've gotten used it, I don't even think about it.

I've heard that a lot of vim folks get similar behavior via tmux and leverage other shell tools.

I'm not going to argue you should switch, because it is an investment. It is like owning a house, you have autonomy but you're also on the hook to fix the air conditioner. You also can't just drop it and move to the next editor. Your hands and workflows become tied to your editor. Keybindings may be similar, but it is not the full story. Either way, it is a journey getting good with your tools, so enjoy it!

For some people (myself included) the infinite configurability is the selling point, and configuration is the 'cost of doing business'. I'm an Emacs person but I'm sure it's the same for (Neo)Vim people too. You're gradually crafting your editor using your editor, and that feels good.

Along the way there are innumberable little choices that you make that shape it into something completely your own. Plus you know it's never going away or getting enshittified because it's open source and has been for decades.

Now, does it actually make you more productive? Or is any productivity you gain swallowed up by tinkering with configuration? That's an open question, and a valid one. People who enjoy an out-of-the-box IDE experience are fine by me - different strokes and all. I just enjoy working in an environment that is always gradually evolving according to my needs, even if it means putting in the work.

I think there's a faction of vim/emacs users who use it because that's all that was available when they started out. vi and emacs are ancient- nearly 50 years old. PCs introuced IDEs (think Turbo Pascal) in the 80s, but there really wasn't anything like this in the Unix or VMS world. So if you started programming for non-PC, non-8-bit machines, you would certainly have encounteded vim or emacs early in your career. I'm one of these people.

There's another faction, of users who have come to vim/emacs in the era of decent IDEs. I think a lot of these people have come in due to the keyboard focus of these vs. IDEs, or because they are very quick and responsive (though recent IDEs themselves are finally really fast, too), or due to aesthetics or because it's percieved as being "hardcore" or "cool".

IMO if you're productive with what you're using now, stick with it. But try other things and see if they click. This goes both for the Unix graybeards and the IDE kids.

You need to eat the upfront cost of learning to use vim's keybindings effectively. Once you've done that, you can edit text files quickly and efficiently on any Linux box from the last 30 years or so. Having an editor you can run right in the terminal, Ctrl+Z out of to run some commands, and then `fg` to keep hacking away is an incredibly powerful way to make using the terminal much lower friction.

Beyond that?, I just run LazyVim unmodified. It supports Copilot out of the box, which was my killer feature for it. Last year I even wrote a set of shell scripts I can curl into any new Ubuntu machine to fully automate all the setup for me, which might be of use to you as well, if you want to skip all the configuration. It also installs fzf, fd, rg, and a whole bunch of other useful tools all at once.

https://github.com/hiAndrewQuinn/shell-bling-ubuntu

Can't speak for vim, but with emacs it's a lot like building your own lightsabre. If you want to invest the time, it can be very rewarding, as you're basically building your own tool chest full of your own customized tools.

But it does take time, and doesn't come "out of the box" with the creature comforts you're probably used to, and has "weird" ways of doing things that are very old but there's usually good reasons for them.

What I like about Emacs is that there are a lot of opportunities to automate away little things. For example, you can make it update copyright years automatically or define a template that will be automatically inserted into all files of a certain type under a certain directory (and that text is itself programmable).

What I like about neovim is that it's as fast as greased lightning. If I could say the same thing about Emacs there would be no competition.

If you’re not loving it then don’t waste your time on it. Use the tools that suite you. Getting into vim is a commitment to configuration, I’ve probably spent close to 50 hours of my life configuring this little text editor. It’s been relatively fun, but mostly because as soon as I started getting into it I had the bug to make it perfect for myself. I ended up switching to VSCode with a neovim extension and my life improved significantly lol

FWIW, I settled on using both. Vim with a simple config and Jetbrains(with vim plugin) when I want all the bells and whistles. Using both equally for coding.

My simple config does include vim-commentary, vim-surround (both supported by jetbrains too) and fzf.vim.

I will preface everything with: if you don't see yourself getting value out of vim... don't use it. It's that simple. Vim has been one of the greatest things in my life for most of my life, but that doesn't mean it will be for you. Everybody is different.

Also, I started using vim basically at the same time I started using Linux and really learning to program. There were plenty of other editors and IDEs around at the time. Even for the languages I was learning. I still use vim, but not those editors.

I will break vim into two parts: its philosophy(s) and its technical implementation. I think both are valuable, but for separate reasons.

First the technical implementation

Because I've been using vim for so long and from such a foundational stage for me, vim is largely just how I think about editing text now. Not just insert vs normal mode, either. Vim includes a whole host of features for editing text. I've been using it pretty regularly for many years now and still learn about new features. The rabbit hole is huge.

To the point that I find a lot of plugins either re-implement built-in features or outright go against the philosophies in vim (more on this later). Personally, I spend as much time (or more) trying to remove plugins as I do trying to find new ones to solve a need.

Plugins have better SEO, but worse integration with the editor, on average. Because of this, I might use a plugin for a bit just to solve a need, but then upon reading up on vim documentation (some of the best around), I might find a way to do something better than my current plugin-based way.

A frequent example is when I need to open a file that doesn't have built-in highlighting support. Instead of adding another plugin that might include more than just syntax support, I might really just need to alias it as another language. e.g. Jenkinsfiles are mostly just Groovy, so the following line is all I personally needed to make editing Jenkinsfiles in vim acceptable [0]:

au BufNewFile,BufRead Jenkinsfile setf groovy

None of that is to say "don't use plugins". Some people use hundreds of plugins, others use zero or very few. Both are correct. Personally, I still think that it's really easy to get carried away with plugins in attempts to try and turn vim into vscode or an IDE. If that's your goal, save yourself a ton of headache and just use vscode or an IDE. Truly ask yourself what it is you are trying to achieve with vim and work towards that, not feature parity with a completely different piece of software. [1]

Probably the biggest watershed moment for me was learning to use vim's buffers to manage multiple open files instead of always using vim's tabs. It has tabs, but they are a different metaphor from "tabs" in most editors. That still resulted in me adding a plugin to display open buffers at the top of the view, but that is an incredibly simple plugin that augments built-in vim functionality rather than try to shoehorn vim's tabs to work like tabs in other editors.

Getting a bit more philosophical

If you'll pardon a somewhat-forced metaphor, vim is a box full of handtools, not an all-in-one power tool. Each one can accomplish the vast majority of what the other can do and neither is inherently better than the other, but their ways of doing so differs greatly.

In particular, vim (like handtools) expects you to learn how to use it. It expects you to not only read the manual, but to keep referencing it and gradually learning new techniques for doing things. It expects you to sharpen it. It expects you to oil it. It will cut you if you abuse it [2]. This is also true for the power tools and other editors, but the whole point of using those is that your expected learning and maintenance is greatly reduced.

The payoff for those years (yes, years) of dedicated learning, at least in my experience, is that you will have a closer understanding of how the tool works. You will gradually develop a sense as though the tool itself has wants and needs. To be entirely too romantic, it is a symbiosis. Again, the way I think about editing text is in vim's commands and metaphors [3].

The other reward for that time spent is that vim doesn't really change. Sure, it's still updated (thankfully) and gets new features, but it is glacially slow to really change anything fundamental. This is often cited as a bad thing, but I personally love it as it means I can depend on it. I don't have to worry about my tool changing out from under me. That is rare in software, especially these days.

Sometimes even a master woodworker might still need a 3D printer, but having mastery over a hammer and chisel can pay dividends.

[0]: That line creates an autocommand for whenever a file called Jenkinsfile is opened or read, set its filetype to groovy instead.

[1]: There is an old article called Linux Is Not Windows. It's been a while since I've read it, so I might not agree with everything in it, but it presents a really great point: the only way Linux can be better than Windows is by being different. That means you will have to change your mindset before you understand it and/or like it.

[2]: Pretty big stretch here. It's not buggy and won't really do damage. I really just mean "cut" as more of "will be slower/harder than it might be otherwise".

[3]: I should point out that, while tools like vscode have plugins and settings to emulate vim's commands and a couple of modes, I have always found those lacking for my needs. I hope it's clear by now that vim is far more (to me, at least) than just using hjkl to move, dd to delete a line, etc.

Lazyvim can help. https://lazyvim.github.io/

> Transform your Neovim into a full-fledged IDE

Just install lazyvim and you basically have everything you need! A few languages are already configured as lazyextras so it's easy to add what you need

Only if you have carpal tunnel problems or painful arthritis, it will make you happy and as productive as a normal developer with vs/vscode/jetbrains/etc

The amount of time you need setup *vim in order to make it a useful editor is not justified, i have seen people waste weeks on it and the only reason is if you have a condition that vim helps to masquerade.

Personally m waiting to get enough money to justify a kinesis keyboard, that will the only reason to improve my neovim knowledge... as for the moment the vim keybindings for vscode are as good as neovim.

Something like gvim is relatively easy to get into if you can give it a few days and look some things up.

Neovim is bizarrely confusing and difficult to configure. The UIs are all weird terminal windows with no buttons, it isn't clear which of the dozens of folders are actually being used for configuration files, it isn't clear how the actual attributes are being declared, it's a disaster.

If I had to guess, it's because terminals don't know what a cursor is. From the terminal's perspective, it is just told to print a solid blinking block at a certain location. Neovide knows what the cursor is because it is communicating directly with Neovim.

A terminal could do this, but there would need to be direct integration into Bash, ZSH, etc.

There has been a large amount of open source to improve window management, I'd say check again!

This is also occurring on my Mac

Oh, neat: https://github.com/helix-editor/helix/issues/39#issue-908964...

Looks like a Neovide author wants to abstract Neovide to support other editors! Imagine that's a big lift, though.

these kinds of things are already possible (albeit without animation) with native features:

- https://neovim.io/doc/user/pi_paren.html - https://neovim.io/doc/user/lsp.html#lsp-highlight

This plugin does a decent job of creating margins, but can only display one text buffer at a time. https://github.com/folke/zen-mode.nvim

Another good plugin for this is https://github.com/shortcuts/no-neck-pain.nvim

You could either branch your Neovim configuration on `vim.g.neovide` [0] or start Neovide (and the underlying Neovim instance) with a different config file by setting XDG_CONFIG_HOME.

https://neovide.dev/configuration.html#hello-is-this-neovide

I think the answer to your question is "yes"; Neovide is just a client for an underlying Neovim process. That process can be local or remote.

I am a pretty big terminal user, and I still use a graphical front end (specifically Neovide and Neovim-Qt). If you are happy with the terminal, you're right, there's no "upsell" here, but if you're happy with something, why would you switch to something else?

I use a graphical frontend precisely because I was unhappy with the terminal, and not because I am stupid, inept, or lazy.

For one thing, a graphical interface liberates you from constraints on key binding, fonts, and colors. Whether any particular graphical interface implements such improvements is up to the developer. But that's the beauty of the whole system: unlike with Gvim, none of that has to be upstreamed into the main application.

Neovim-Qt also offers a couple of interesting features like native scroll bars, a tab/buffer line made of native "tabs" instead of drawing it with plain text, and a native right-click menu. It also has some kind of adaptive color thing, for people who really like to "rice" their system and get a uniform look and feel across applications.

Something to keep in mind is that all of these projects are relatively new and developed by hobbyists. It will take years and years for any of them to reach feature parity with Gvim.

> Ligatures: ok, nice, possible in terms too (hopefully Alacritty one day)

I wouldn't hold my breath. Seems like its getting the iPad calculator treatment[0]. Which is to say rather than ship something working that can be improved, they're leaving a UX void.

[0] https://github.com/alacritty/alacritty/issues/50

I'm a big fan of Emacs and evil-mode, but I wouldn't say it qualifies as "no-nonsense". :-)

It took me the better part of a weekend to get Doom Emacs (which defaults to evil-mode) working on par with VSCode.

I'm not certain what "the background color is deprecated" means but I really don't like the sound of that.

Sure. But it also brings joy.

The point of railgun animations is not to distract you, but let you focus faster since it shows the path between the start and the end, which is especially helpful when cursor travels large distances.

So it adds no delay, has a very focused practical purpose, in what way is this "nonsense" UX preventing your from getting stuff done?

Yes:

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

There are quite a few GUI front-ends options available:

https://github.com/neovim/neovim/wiki/Related-projects#gui

It's not officially part of the Neovim project. However they distribute it with the Windows installer.

Neovim-Qt and Neovide both work the same way, one is not more privileged or official or well-integrated with Neovim than the other.

Yeah but I don't find any upsides compared to nvim running in a modern terminal emulator like Konsole, Alacritty or WezTerm.

There are a bunch of them. None are really good IMO.

Works fine for me on the same.

brew install for me is working fine (with lazyvim)

You can have hover support even in a terminal nvim instance, so maybe that's just not a distinguishing feature.

Neovim has an RPC API specifically designed to allow GUIs to render it outside the terminal. Neovide isn’t treating it as a generic TUI.

https://neovim.io/doc/user/ui.html

What's wrong with the native keybindingings? The simplicity to bind any command, even external programs or scripts is one of the best features of vim. For example I have leader+m to compile based on my current filetype, leader+d opens the binary in :termdebug (gdb) and many, many more. I keep adding to my config anytime I get sick of a repetitive action.

You don't need anything fancy to do what you're asking, except for holding a key, which AFAIK isn't possible. Some bind j+k to esc in insert mode. I don't like messing with the characters in insert mode because it creates latency and fucks with my typing but I swap esc and caps since esc is my most used key, and caps my least.