Neovim 0.8 Released

https://github.com/neovim/neovim/releases/tag/v0.8.0

by akrifari • 4 years ago

326 221 4 years ago

alwillis12• 4 years ago

Just built it from source on a beta of macOS Ventura… everything went smoothly. These guys have done a great job.

That's a LONG list of fixes & features. I'm fairly new to vim (using Neovim as an IDE to learn Rust) but I'm very tempted to pull and build this release.

dyingkneepad2• 4 years ago

Neovim is one of those things that seem maybe cool, but I just can't find a reason to switch. Vim works just fine for me, I don't know what I would be getting by switching, and I'd probably waste some time porting my config and workflow to whatever the differences are (I'm a heavy user of :terminal).

Jenk• 4 years ago

Neovim is vim 8 compatible. It _also_ supports LUA script for config and plugins, has native LSP support, and runs much more efficiently.

You can run your current .vimrc using neovim.

Normille• 4 years ago

  >Neovim ... supports LUA script for config and plugins

Except it doesn't really. Or at least it's very basic. I'll re-post a comment I made on this, when it was discussed a while back [0]

https://news.ycombinator.com/item?id=32624308

----

I've been using Neovim for several years now. Not for any real reason, other than "Let's try 'new & shiny'" when it first emerged. Last week I thought I'd finally get round to converting my existing Neovim init.vim config [which had itself been inherited and developed from my earlier Vim .vimrc one] to Lua [not a language I'd ever used before. But the syntax looked fairly straightforward].

What a waste of time! The easy stuff [enabling/disabling various options] was easy. But then it's easy in Vimscript too. The difficult stuff [defining autocmds, managing my plugins] was either completely ignored in every single "convert your init.vim to to init.lua" tutorial I read... or required wrapping the existing Vimscript block in

  vim.cmd[[ ... ]]

in Lua because Neovim's Lua support can't yet do a lot of this stuff natively. Oh, and this also had the brilliant side-effect of removing syntax highlighting from great swathes of my config file as everything inside vim.cmd[[ ... ]] is rendered as a comment. I spent the best part of a day wrestling with converting to init.lua, left it overnight and then, in the morning thought Why the fuck am I wasting time trying to beat this into shape, when my existing vim.init is already set up exactly how I want it?" and I reverted back to good ol' crusty ol' unfashionable Vimscript.

YMMV if you're actively developing plugins and want to use a more widely utilised language to write them in. But for configuring Neovim itself, Lua is more hassle than it's worth.

cool_hw3• 4 years ago

Treesitter integration is a bit easier in neovim IMHO (but I haven't tried to make it work with vim too much.)

Newer plugin development seems to be much more on the nvim side than vim as well. (Although I do feel fzf is superior to telescope, at least out of the box.)

I'm happy neovim exists, it rekindled vim development.

Also, someone correct me if I'm wrong, but isn't the bus factor 1 on vim?

Beltalowda2• 4 years ago

Also, someone correct me if I'm wrong, but isn't the bus factor 1 on vim?

There's a bunch of people who are "members" of the vim organisation on GitHub. I don't know if they have full admin privileges or just commit/issue access. I never really understood why this has to be a problem in the first place: can always clone the repo and continue working on it if Bram disappears.

qudat• 4 years ago

Plugins built with lua, lsp, treesitter for syntax highlighting are the big ones.

https://neovimcraft.com — For neovim specific plugins

tomjakubowski3• 4 years ago

Yes, treesitter is a sea change. Besides the quick and error-tolerant syntax highlighting it provides, plug-ins which use it to manipulate syntax are remarkably fast and accurate.

freedomben2• 4 years ago

Yeah it's a tough one. I've switched back and forth relatively freely over the years, but now that new VimScript (vim9 script) has breaking changes and neovim will not be supporting it, it's probably time to pick a pony.

I may end up sticking with og vim but my heart has always been with neovim. regular vim would undoubtedly still be stuck in the stone age (including with no :terminal) had neovim not started some competition. I get the feeling that VimL's evolution was done in a way that made it quite difficult or impossible for neovim to merge/rebase into. Hopefully that wasn't intentional.

yoyohello13• 4 years ago

The creator of Neovim's LSP integration is currently working on a VimL9 JIT compiler to make Vim9 plugins work for Neovim (early stages). So you still may be able to stay on the fence.

alwillis12• 4 years ago

Vim has had :terminal since version 8.1 [1].

[1] https://gist.github.com/mahemoff/8967b5de067cffc67cec174cb3a...

asdfqweqe12• 4 years ago

Telescope is must have for me.

https://github.com/nvim-telescope/telescope.nvim

cool_hw3• 4 years ago

fzf.vim works better, in my subjective opinion, but I haven't configured telescope a lot.

codetrotter• 4 years ago

From the opposite side, I decided a few years ago to use neovim in place of vim, and there were no drawbacks to making the switch for me.

Then again, most of my time these days I spend in JetBrains Clion with Vim emulation, as it is much better suited to the kinds of projects that I currently work on than Vim or Neovim ever was. So take my opinion on Vim vs Neovim with a grain of salt.

pletnes• 4 years ago

The big downside is having to install neovim. Good old vim is in macos, git bash on windows, any random vm you’re thrown into… I also use the vim plugin for intellij et al, but I use vim on all the raspberry pi’s, weird windows boxes with some issue, and so forth. It’s already everywhere and neovim isn’t.

bilekas• 4 years ago

Personally I switched purely because of lua, I don't really gel with the vimscript.

ainar-g• 4 years ago

Back in the day, Neovim has always felt about three times snappier than Vim (I think it was Vim 7.2). Also, I don't remember if the newer versions of Vim have it, but Neovim has native LSP support, which is also very nice.

maxoid• 4 years ago

the reasons why i switched to nvim:

- configuring in lua (much easier than vimscript, imho) - treesitter - built-in language server protocol - plugins (id call them "projects") like telescope

alwillis12• 4 years ago

Your .vimrc will probably work as-is without much work from you.

Plus Vim and Neovim can co-exist on the same machine without an issue to try it out [1].

[1] https://neovim.io/doc/user/nvim.html#nvim-from-vim

Cupprum• 4 years ago

I switched to neovim because of LSP (Language server protocol) support. I know there are libraries (or whatever cool kids call it these days), which brings this functionality to og vim, but the lsp integration in neovim just works so nicely out of the box.

styren• 4 years ago

Hold on, you don't need anything like Ale or CoC to run LSPs in neovim?

vibrant_mclean• 4 years ago

og vim does not have full lsp out of the box. However it does have the the api and options to implement one easily.

see: https://vimhelp.org/channel.txt.html#language-server-protoco... https://vimhelp.org/channel.txt.html#channel-mode

StevePerkins• 4 years ago

I think the selling points are supposed to target plugin authors, and people who like to use a ton of plugins.

However, I would imagine that well over 90% of Vim users don't use a single plugin. At all. They defined some look and feel defaults in a ".vimrc" file 10+ years ago, and never thought about it again. At least that's my user profile, anyway.

So to me, the NeoVim story is mostly Internet drama, about some salty devs who didn't get their patches merged and have been publicly jihading ever since. It's not enough to merely use NeoVim, you have be angry about it.

jasonpeacock2• 4 years ago

In additional to all the features that others mention, I chose to support the Neovim project. It's a more open alternative without a BDFL that is willing to move forward and modernize the editor, drop support for ancient platforms, and regularly release improvements.

A big deal was splitting the editor engine from the interface so that it's embeddable in other editors.

da4id• 4 years ago

I tried moving to neovim from vim mainly to try Copilot.

sgk284• 4 years ago

Vim user for 15+ years here. Switched to neovim last December to try out Github's Copilot plugin (which only supported neovim), and it was basically a drop-in replacement for vim. And I haven't looked back.

I'm also a heavy user of terminal though, and that was the one thing I spent extra time on, because there were subtle differences that I didn't like. If you give neovim a shot again, try this in your ~/.config/nvim/init.vim (aside: I do miss the simpler path of ~/.vimrc):

  " Neovim's default terminal mode bindings aren't great.                                                                  
  " This makes them behave like vim's.
  tnoremap <Esc> <C-\><C-n><C-w>
  tnoremap <C-w> <C-\><C-n><C-w>

  "Always enter the terminal in insert mode
  autocmd BufWinEnter,WinEnter,BufEnter term://* startinsert
  autocmd TermOpen,TermEnter * startinsert
  command! -nargs=0 Terminal :vsplit | term

This allows navigating across splits more seamlessly, and I like defaulting to insert mode whenever I move into a terminal. I also added the :Terminal command because I prefer them in a vsplit by default.

efficax• 4 years ago

when i switched to neovim, vim did not have :terminal and that was the real killer feature to me. neovim also had better async communication support than vim did. vim caught up, but in the meantime i had already gone full on nvim. Now, with the lua support, there's no way to make my config compatible between the two, and i'm "stuck" on nvim.

dyingkneepad2• 4 years ago

Embrace, extend, extinguish!

suprjami• 4 years ago

I switched because the cursor handling is nicer in neovim. It puts a bar when editing so you can see if you're inserting before or after a character, and an underscore when operating on a single character (like after pressing "r").

The former sucks to do in vim, I couldn't get it working in tmux at all, and I don't think the latter is possible?

Apart from that I'm treating it like vim and using all my existing vimrc and vimscript plugins. It's been good.

coinbasetwwa• 4 years ago

I still haven’t recovered from the last couple updates… I’ll probably be making the switch to VIM very soon.

ollien• 4 years ago

Do you mind elaborating?

kuratkull• 4 years ago

You make it seem like some obvious things were recently broken/changed. I have used NeoVim for a couple of years, I haven't noticed any breaking changes. Please elaborate

hyperpl• 4 years ago

Hi could you please elaborate?

renewiltord• 4 years ago

This is possibly my favourite kickstarted project. I use this every day and got far more than my contribution was worth. Quite happy.

My latest thing is I use it with C-x C-e in the terminal and copilot.vim to get shell autocompletions!

hd4• 4 years ago

They added a msi installer since 0.6 so that's pretty cool

g_delgado14• 4 years ago

Dumb question; what's an msi installer?

freeCandy• 4 years ago

The installer for Windows https://en.wikipedia.org/wiki/Windows_Installer

BaculumMeumEst4• 4 years ago

I really wish neovim could ship usable default colorscheme and round out its lsp support with autocompletion. Treesitter isn’t for me; it’s slower to open files and I have no idea how people make sense of so many different color groups.

Still sticking with vanilla vim and CoC for the time being, they’re rock solid.

alwillis12• 4 years ago

Treesitter isn’t for me; it’s slower to open files

I certainly haven’t experienced any slowness with opening files with Neovim with Treesitter. It certainly enables much better syntax highlighting, among other things [1]. If anything, it’s faster than the regex-based syntax highlighting that Vim traditionally used.

CoC is a 3rd party LSP plugin that works with Vim and Neovim.

[1] https://neovim.io/doc/treesitter/

BaculumMeumEst4• 4 years ago

Treesitter is slower to parse a file initially but quicker at handling incremental changes. You probably won’t notice unless you open a huge source file.

yjftsjthsd-h7• 4 years ago

usable default colorscheme

What's wrong with the default colorscheme?

BaculumMeumEst4• 4 years ago

https://ibb.co/TR9sWj8

thetic• 4 years ago

This is planned for the next release: https://github.com/neovim/neovim/issues/14790

sva_• 4 years ago

Finally I can get off the dev branch (which has been extremely stable though)

sigmonsays• 4 years ago

can't have a vim discussion without someone bringing up emacs

jhoechtl• 4 years ago

Emacs gas sub-par treesitter support and will go by default with eglot which is ok but nowhere as polished as the lsp experience in Neovim.

ajoseps• 4 years ago

I've tried using neovim for C++ dev but keep ending back in either vscode with intellisense or YCM on Vim. I don't know if I'm just misconfiguring things but I haven't been able to get autocomplete working correctly. Any tips?

ckolkey4• 4 years ago

https://github.com/hrsh7th/nvim-cmp should be the ticket

simjue• 4 years ago

I've also tried using vim/neovim etc. several times but had the same problem. Recently I've tested lunarvim and autocomplete worked out of the box (with Go).

addcninblue• 4 years ago

You'll need to configure clangd or ccls correctly with neovim's lsp, which in turn requires your build chain to be clean. It's definitely a huge time sink. Feel free to email me if you have specific issues!

ativzzz• 4 years ago

I was doing a school project in c++ and I tried configuring ccls but in the end I just gave up and did the project without LSP. Like you said it came with some prebuilt tooling and ccls did not feel particularly beginner friendly to get working as I am not familiar at all with the c++ toolchain.

It (mostly) worked out of the box in another project with only some minor quirks though

NaN1352• 4 years ago

Any neovim based "gtk vim" app on linux?

gVim is so slow for me, can literally see the window text redraw from top to bottom, where sublime text or vscode switching tabs or scrolling is near instantaneous.

ckolkey4• 4 years ago

Something like https://neovide.dev/index.html ?

modernerd9• 4 years ago

If you use Neovim, can you share why you chose it over VS Code, or one of the new terminal-based editors like https://helix-editor.com/, or new native GUI editors like https://zed.dev/ ?

It's impressive to see what the Neovim community has built — preconfigured setups like https://nvchad.com/ are especially wild. But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed, which are pretty great out of the box, and which were built to be used as rich development environments instead of extensible text editors.

I've spent months tweaking Neovim/Emacs configs in the past and I ultimately end up conceding that I'd rather spend that time hacking on projects instead of my editor config. I do feel the pull of these editors, though. I'd love to understand what those who stick with them are doing differently, other than perhaps being more susceptible to sunk cost fallacies. :-)

ibotty• 4 years ago

Because it's vim but better. I don't want an editor that uses, maybe, eighty megs and is constantly swapping!

qbasic_forever• 4 years ago

I don't need parity with VS code. If I want LSP and all kinds of distractions, binging and bonging, and crap jumping out and highlighting at me... I'll use VS code (don't get me wrong, sometimes those distractions are useful).

Sometimes I need a terminal text editor. Something to quickly edit a config file, or perhaps even write something more substantial. Vim and Neovim are perfect and available on pretty much any machine which you'll have a terminal open to access.

stoplying1• 4 years ago

Helix is just very, very excellent. I've spent less than 5 minutes total configuring it and I really have virtually not a single complaint and there's WIP for the niceties that aren't present yet (sidebar/treeview, etc).

I installed it, had some LSPs already on path. I configured it to show LSP messages and that was about it. It's very cool how gosh darn productive I can be, in such a short time due to the command palette built in.

Seems like folks are taking note too. There's a few intro videos on YouTube that do a good job posted in the last few weeks; apparently some big Vim-guy streamer checked it out last week. Active Matrix room and constant code improvements. And native nix flakes support too ;)

Btw, I find it a bit weird to include VsCode and Helix here together. Helix is perfectly usable as a Vim replacement for all basic text editing tasks, and a superior zero-config alternative in countless other scenarios.

modernerd9• 4 years ago

I'm looking forward to a treeview too!

https://github.com/helix-editor/helix/pull/2377

And subsequent icon support:

https://github.com/helix-editor/helix/pull/2869

I find it a bit weird to include VsCode and Helix here together.

I work with people who declared config bankruptcy, switched from Emacs/Neovim to VS Code, and are perfectly happy and (maybe even more?) productive as a result.

VSC is not in the same category as vim but it seems to appeal because it's a halfway house between vim/Helix and a heavier IDE. John Carmack even said something similar about VSC in his Lex Fridman interview:

01:11:31.060 And I am super happy that that seems to be winning

01:11:33.540 over even a lot of the old Vim and Emacs people

01:11:36.140 that they're kind of like,

01:11:37.140 hey, visual studio code's maybe not so bad.

01:11:40.060 I am, that may be the final peacekeeping solution

01:11:43.260 where everybody is reasonably happy

01:11:45.620 with something like that.

https://karpathy.ai/lexicap/0309-large.html

simonsaysso• 4 years ago

The sunk cost fallacy is real.

Most important to me when I started tinkering with him was the speed/feature tradeoff, and portability. I was working on 7 machines at one point doing pretty quick edits of config files and Python scripts, so launch speed and availability across different environments drive me to vim.

Now there are alternatives, but back in 2015 these were all in their infancy. And now I _know_ vim and it keep adding more features. The incremental cost of adding language server support is much less than the cost of learning how to move around VSCode, so my (neo)vim config keeps growing slowly but surely

__s• 4 years ago

I have a simple .vim setup which I can use across multiple machines: https://github.com/serprex/.vim (I know there's simpler out there; I haven't spent time pruning my config down)

I prefer sticking to full terminal UI

When I used vscode I was frustrated by vsvim's latency & missing features (macros tended to have holes)

I didn't start using vim until I'd been programming for a decade already. Before that I mostly used SciTE

You may be more susceptible to over tinkering. In the past few years the most I've tinkered with my setup was when I decided to try out neovim's lsp feature, where previously I'd been using coc.nvim

divan• 4 years ago

I tried to use Helix and really liked it, but had to stick with Neovim because of Copilot.

modernerd9• 4 years ago

I also really like Helix. Looking forward to:

- Reload of files changed on disk: https://github.com/helix-editor/helix/pull/2653

- Autosave: https://github.com/helix-editor/helix/pull/3178

- Git/SCM support: https://github.com/helix-editor/helix/issues/227

- Extensions (potentially enabling Copilot support): https://github.com/helix-editor/helix/pull/2949

jefftime• 4 years ago

I actually loved Helix, but moved from it to Neovim for performance and customizability reasons. Helix becomes unusable with multi thousand line files, but I imagine it's something that will eventually be solved as the project matures. The customizability of Neovim is incredible, and I'm looking forward to trying Helix again when it has a plugin solution

rockwotj2• 4 years ago

I enjoy a terminal workflow, and helix doesn't actually have vim key bindings and many years of vim use is hard to switch.

EDIT: I'm also a tmux user and I can't live without a replacement for this plugin: https://github.com/christoomey/vim-tmux-navigator

norman7844• 4 years ago

Check wezterm, it has something similar to tmux splits and it's nice.

yjftsjthsd-h7• 4 years ago

If you use Neovim, can you share why you chose it over VS Code, or one of the new terminal-based editors like https://helix-editor.com/, or new native GUI editors like https://zed.dev/ ?

VS Code is a proprietary, spyware-riddled, resource-wasting worked example of why "modern" software sucks. Also for my personal use, everything that's not vim suffers from being not vim; it would cost me effort to switch for no clear benefit, and I'd still need to retrofit the same control scheme into whatever it was because the muscle memory is too strong, at which point I might as well just use actual neo/vim.

which were built to be used as rich development environments instead of extensible text editors
spent months tweaking Neovim/Emacs configs

I think part of the difference might be of usecase; if you want an IDE, use an IDE. If you needed to spend that much time bending the tool to what you want, maybe it wasn't a good tool to use. When I open vim, it's because I want a text editor, and it provides a text editor.

cercatrova2• 4 years ago

I use VSCode since switching away from Neo/Vim because things just work. I don't have to install a bunch of plugins like I used to where I don't know what works and what doesn't work with each other. For example, for Rust, I go to VSCode extensions page, click install on rust-analyzer, and that's it. I don't have to set up an LSP, syntax highlighting, etc which are each their own plugin on Vim.

d3nj4l• 4 years ago

If VSCode "sucks", then isn't it weird that the vast majority of people seem to love and even prefer using software that "sucks", including GP?

johnfn6• 4 years ago

VS Code is a proprietary, spyware-riddled, resource-wasting worked example of why "modern" software sucks.

Perspectives like these (and others in the thread) remind me that there exists a separate cohort of engineers from people like myself which have absolutely polar opposite views. I respect your opinions, though I couldn't disagree more with them! :)

Well, except the bit about VSCode having "spyware". That's not true, and it weakens your point. It does have telemetry - I suspect that's what you mean, and you should just call it that instead.

peppermint_tea2• 4 years ago

on linux, kde/kate is pretty good... I switched back to full tmux+vim lately to get even better with vim, but I find that kate is the perfect mix between an ide and a terminal based editor. makes me think of notepad++ with a few extra goodies (files on the left, terminal below etc...)

wyclif2• 4 years ago

Hmmm, did some of the mappings change with this release? Now hitting CTRL-B (I do that a lot in NERDTree) gives me the "E5248: Invalid character in group name" error.

rmolin88• 4 years ago

Neovim is extensibility and versatility. If you want a rich development environment, you can put in the work, or use one of the many preconfigured environments, and turn neovim into that.

If you want a bare ultra fast, terminal text editor, neovim is that out of the box.

If your only after LSP, tree sitter, embedded terminal, neovim's got your back.

Basically, neovim embodies the beauty of Linux. Use and pay only for what you want.

Blackthorn• 4 years ago

The reason I still use emacs over helix or zed: elisp.

Not because I particularly like the language. But because I like that I can write something in a language that executes and accesses pretty much anything the editor can do.

Does helix or zed have the ability to do that? I didn't see it on their landing pages. What are the extensibility stories for these editors?

modernerd9• 4 years ago

Zed and Helix are both pretty new.

There's demand for plugin frameworks/scriptability in both but neither of them support it yet. I fully understand why people who need to script their editor are sticking with [neo]vim/Emacs — there are very few other options at the moment.

https://github.com/zed-industries/feedback/issues/388

https://github.com/helix-editor/helix/discussions/3806

tomjakubowski3• 4 years ago

Don't know about hex/zed but Lua in neovim is just about as pleasant to use as Elisp is with Emacs. It's not quite the same thing since neovim's still largely written in C, where Emacs is largely written in Elisp. But most of the editor's features (including text manipulation) are exposed to Lua.

Lua is a nice language too, just lacking the stuff that makes the Lisp nerd in me happy.

jasonpeacock2• 4 years ago

Because when I started using Vim, VSCode and Helix weren't around. And now I know Vim (Neovim) very well and it does everything I need - I'm productive with it and it's lightweight.

I don't want a full IDE/graphical editor. Eclipse is a mess, I'd use a JetBrains product first, but now we have VSCode as an alternative. Atom was hot for a while but has lost popularity.

Of the (linux) terminal text editors, the choices were mostly:

* Emacs * Vim/Neovim * Nano

And I prefer Vim over Emacs, I really like the modal experience.

I don't spend a huge amount of time tweaking things, I use Neovim mostly stock with some useful plugins for convenient shortcuts. Though I admit that getting the new treesitter/language server integrations working was annoying, compared to the original regex-based syntax highlighting.

My goal is not to recreate an IDE experience in Neovim, I just want an efficient text editor that is syntax-aware.

If I wanted an IDE then I'd use an actual IDE.

threatofrain• 4 years ago

Helix is nice but Zed development speed appears to be a bit slow for my liking.

weaksauce• 4 years ago

you can use neovim inside of vscode. it's pretty alright with only a few things that are rocky. I like it. got that modern gui affordances with the plugin ecosystem and lsp baked into it hard but also the normal/visual mode power.

modernerd9• 4 years ago

Thanks, I use VSCodeVim at the moment because even though it's not using “real vim” under the hood the performance has been more consistent for me.

I revisit VSCode Neovim periodically but end up switching back after a day or so due to consistent freezing and cursor jitter (even with an empty nvim config and very few other VS Code extensions). I'll keep trying it out, though.

ptato• 4 years ago

Modal editing in VS Code is not good enough. I still use it for certain things. Just not the bulk of my programming.

When helix is more ready, I will probably switch to it.

norman7844• 4 years ago

I use both, there are certain nuances with helix right now, like exploring the project structure, there's a sidebar in the works, but is not ready yet, also when you need to create new files I find it easier to do it in vscode.

bilalq• 4 years ago

I kind of take the best of both worlds. VSCode has a lot of functionality that Neovim lacks, particularly on rendering previews of things like Markdown and Mermaid. Even outside of UI stuff, VSCode's extension ecosystem has so much deeper integration with things (beyond the level of just text/code editing, I mean). The VSCode JS Debug Terminal is literally life-changing. No more needing to mess around with debugger configs for runtimes. Literally just run the code and it works.

Despite that, I still often feel limited by the vim binding plugin for VSCode. It's never a problem though, because Cmd+J toggles the terminal visibility, and I escape into Neovim there when I need it.

Beltalowda2• 4 years ago

I like "simple" editors: just text, completion when I ask for it (instead of popping up all the time), no distracting UI chrome, simple syntax highlights, etc. "Simple" is a bit of a misleading term, because even "stock Vim" (or Neovim) has a lot of IDE-like features. They just don't get in your way by default.

I tried VSCode, and after several hours I still hadn't turned off all the features that I found undesirable.

For me, personally, that nvchad thing seems horrendous. I don't know about Helix; maybe it's better, but I can't be arsed to check it out as I don't expect any productivity jump to be worth the effort.

jerpint• 4 years ago

I really like working inside a terminal, and I like being able to navigate seemlessly between code tabs and terminal tabs as though they are one. I can do this easily in vim+tmux, I can't do this easily in IDEs where the mouse is considered first-class. I do miss certain features of IDEs, but being able to toggle between shells, tabs and code is my killer feature.

peppermint_tea2• 4 years ago

I just switched to this setup now... Before, I was using kate (which is very nice) but I switched exactly for the reason you've mentioned. terminal and editor in the same place.

massysett• 4 years ago

I was not familiar with Helix or Zed, so I took a look at the links.

Both webpages prominently state that the editors are written in Rust. This reduces my interest in both projects.

As a user, I do not care what language my editor is implemented in. Maybe I want a fast editor, or maybe I want a feature-rich editor. The closest I would come to caring about this is if I want an extensible editor - can I extend these editors using Rust?

Lacking any explanation as to why I should care that the editor is written in Rust, the conclusion I draw is that the creators of the editor were interested in an exercise in writing an editor in Rust - which I'm sure is a wonderful learning experience for the creators, but I don't see why that would make me interested in using the editor.

dominotw• 4 years ago

As a user, I do not care what language my editor is implemented in.

Perhaps its a proxy for speed. You don't want your editor written in python.

modernerd9• 4 years ago

Don't let the “built|written in Rust” taglines put you off either project.

Both are fast editors built by passionate teams offering compelling out-of-the box experiences. They're worth taking five minutes to download and try (or apply for the waitlist in the case of Zed).

norman7844• 4 years ago

For me the thing is if is written in rust it has more chances to get more contributors, besides all the rust benefits (fast, performant as if it were written in C, but without the worries of the memory issues).

Also just because I use rust, I could contribute, for C/C++ editors I will not be able, maybe I'll also give a chance if the editor were written in Go, but no other language, all the others are slow.

Also rust IMHO has a few apps (including commands) that are worth checking:

- Helix - Alacritty - Wezterm - Nushell - Zoxide - Starship

Then are others to replace grep, and other commands that I cannot remember from the top of my head.

cercatrova2• 4 years ago

This reduces my interest in both projects.

That's funny, it's the opposite for me.

As a user, I do not care what language my editor is implemented in.

I do care. I don't like using Electron apps, even if I have to grudgingly use them a la VSCode. If an app is in Electron or some other slow framework like a Python GUI, my interest immediately drops to zero. If it's in Rust or some other low level language, at least I know it'll be fast.

benreesman2• 4 years ago

I don't get along very well with the HN Rust Community (and I think I'm even less popular with them than they are with me), but fair is fair and the Rust folks have been absolutely revolutionizing the modern terminal experience.

Put differently, I take the opposite view: seeing that a piece of terminal kit is written in Rust gives me a quite high Bayesian prior on the quality and usefulness of the tool. Something like 70% of the command-line nix packages in my home manager are written in Rust.

CrendKing3• 4 years ago

Think this in a jokingly way: since only smart and dedicated people can master Rust, software written by these people must be good most of the time. Just like how literate people in ancient societies are mostly elite class. You don't expect a peasant to write a history book.

Of course, same as how our societies develop, when Rust inevitably become more popular, this perception will no longer hold. One day, Rust will join amongst C and C++ and become tool for everyone. Until then, "Written in Rust" is just a cheap but effective differentiation ad.

Faaak• 4 years ago

I use VSCode, but I installed the vim plugin which makes it handle like vim for user inputs. Best of both worlds IMHO.

reidrac• 4 years ago

I have been using vim since the late 90s, although the experience back then was much different. I don't think I really used plugins until around 2010 or so, and I was more into gvim until I moved to tmux + vim combo around 2016. So my nvim setup is not too fancy (sometimes I try plugins, if in two weeks I don't use them -or I don't even remember how they work-, I uninstall them).

Moved to neovim because it felt faster than vim 7.x and it was fresh and exciting (couldn't believe the progress the project was making in a short period of time, compared with vim). Then I stayed because of the native LSP support and nvim-metals (among others).

Things work, to the point that I'm not really using the editor but editing (if that makes sense). It is completely invisible to me. It is my editor.

sophacles7• 4 years ago

Similar story here. I often liken it to a musician with their instrument, or a master blacksmith with their hammer - at some point the tool stops being a separate entity and becomes an extension of the person wielding it. I think the ability to have this comes from the fact the fundamentals of the tool are stable across decades.

zimpenfish2• 4 years ago

If you use Neovim, can you share why you chose it over VS Code

Just about 30 years of muscle memory for ed, then vi, eventually vim, and recently neovim. Also because one flavour or another is pretty much guaranteed to be available on any server I log into - as a contractor, it's handy to know there's a (to me) usable editor wherever I end up.

I've spent months tweaking Neovim/Emacs configs in the past

I had a brief spell of Emacs madness at uni but then recovered and I've had pretty much the same vimrc since picking up vim modulo adding things like go-vim and surround in the last few years.

Grimburger• 4 years ago

pretty much guaranteed to be available on any server I log into

So is nano, the original comment hits the mark, why exactly can't you use a proper code editor via ssh? There's very little reason these days. Haven't used a terminal editor for a decade despite doing tons of work that many would instinctively reach for the same job.

VSCode and pretty much every other equivalent has modal editing if that's the sticking point here.

3836293648• 4 years ago

Helix has segfaulted within minutes every time I've tried it. Despite being written in rust. It might be better now, but they've already lost me.

I switched away from VSC because I grew frustrated with the constant lag and terrible loading times.

The modern native stuff is either MacOS only or a proprietary newcomer, leaving me with no trust that I can stick with it long term.

And I'm a Nix user, so neovim doesn't randomly break for me, all versions are pinned. And if stuff does break when I chose to update my pinned versions it's trivial to rollback.

scelerat• 4 years ago

Kinda just like the modal editing of vim and the features and improvements upon it by neovim.

These days I've been using the LunarVim suite of neovim enhancements and I like it quite a bit.

https://www.lunarvim.org/

95% of my coding workflow takes place in the terminal (along with tmux and iTerm2) and neovim fits very nicely there.

benreesman2• 4 years ago

vi (and in different ways, emacs) were designed for optimal editing productivity on low-bandwidth connections and low horsepower machines.

This created an imperative around efficiency per keystroke that, somewhat shockingly, remains the most thorough and successful mainstream attempt to get the most from every keystroke.

With modern technology and decades more experience it seems inevitable that someone could do better today (though even with those benefits not everyone is Bill Joy), but I’m not aware of anyone who has successfully attempted to beat vi/emacs for the “will learn arbitrarily hard tools to be fast” crowd, which necessarily counts the “my RSI is so bad I need my money’s worth out of every key press” crowd, and several other big blocks of badass hackers.

People still use these tools because they still have the highest ceilings on the effort/power scalability curve. That doesn’t make them right for everyone, but it makes them right for a lot of people.

celrod• 4 years ago

I use emacs. I have little desire to customize configs and spend hardly any time on it. Checking now, I haven't modified it since June, which means I haven't even installed any new packages (the equivalent of VSCode extensions) since then either.

Maybe I should spend more time on it, but my settings work for me and I can't really be bothered/find coding projects much more alluring than editing a config.

Why emacs, then? Mostly that I like the keybindings more than anything else. Emacs extensions in vs code are a poor imitation at best. I'm not really into modal editing either. Maybe I'd just have to spend the time to learn that, but I'm quite productive with emacs, so I don't see the incentive. I have keyboards with thumb clusters, so it's comfortable and quick to press key combinations in parallel. Switching between modes and executing key presses is inherently serial in comparison. I assume with practice I could get very quick at that as well -- after all, typing is also serial, but can still be fast. I just don't see any value proposition to switching.

_kblcuk_• 4 years ago

I use Neovim exclusively for the past 4 years or so. Before that I used WebStorm + sometimes Vim for another 6 years or so. To this day I'm thankful to my colleague and mentor, who introduced me to the basics of Vim (you know, how to quit it and all that) saying "it get's pretty handy when you need to edit something on the server"; that was probably around 14 years ago.

WebStorm was great, it was really magical how it just knows how this or that code relates to another piece of code, navigating around was a bliss. Where is that variable defined? Jump to definition, and you're there. You want to know what's that function does, even if it's somewhere in third-party libraries? No problem, jump to definition. The fuzzy-finder for everything (literally. From file names to methods to editor's commands and variables) was also amazing.

At some point though I got a bit annoyed with the fact that it took 5 seconds to start it up (multiply that by amount of different projects you need to open), and it's general resource hungry-ness. So I started experimenting with Neovim 0.3 (at the time), and pretty quickly managed to get near-webstorm experience with gutentags, fzf and amazing vim-fugitive for all the git things I did in the command line. And with resent native lsp & treesitter, it doesn't

I tried VSCode once, which was a fiasco -- for some reason it failed jumping to definition in a basic react project with typescript. Oh well.

Helix looks really cool, I'm playing around the idea of using it more, though I still will have to keep (Neo)vim around for vim-fugitive. Slightly concerned with how much muscle-memory re-training will needed though, then again it didn't took me too much to get to the same level of ease of use with Doom Emacs. Speaking of which, it worked flawlessly (and has even better git tool), but still was terribly slow at times, so in the end got too annoying to work with.

So in the end it boils down to Neovim being fast, not getting in the way, and habit, I guess.

malikNF• 4 years ago

In addition to programming, part of my job involves doing linux admin stuff, when I login to a server I expect vim to be there, and if not it takes a few seconds to install it.

I usually try something on my local machine and switch to the server and do this back and forth and sometimes the other way around, I have a test server where I test something before trying it on my local machine. Having the same text editor on all of these environments mean I don't have to context switch much, also I have my own custom config which I have been improving over the years and the fact I have multiple vim instances running right now and they are all consuming less than 120MB memory and the fact it responds really really fast is a really nice addition.

When I first started using vim I remember I asked one of my friends the following, "what the hell is wrong with people, why do they love using this god awful garbage" I remember my friend asking me to keep trying for a little while longer. Thank heavens I took his advice, I can't really remember when it happened but one day it just made sense.

Then I saw a neovim config file, and how good it looked with lua scripting, changed my old vim config in to a neovim one, and now I use neovim.

(plus I still have trust issues with a certain multi billion dollar company)

jofer• 4 years ago

I can't really agree that VS Code or Helix are "great out of the box". I haven't tried zed. VS Code feels really awful to me (note: this is probably just me) without weeks spent re-configuring it. Even then, it's _way_ too heavy for my laptop to run reliably. Maybe my brain just works differently, but I feel like VSCode fights against me at every turn. Helix is nifty, but also feels like it gets in my way more than it helps.

I've never understood the advantage of "rich development environments". The refactoring tools and other fancy aids seem to never work. I wind up using regexes + manual intervention anyway. Also, I don't want to use git through a gui. Leave me be in the terminal where I have everything I need at my fingertips as fast as I can think.

Syntax highlighting, linting, completion, and docs are all nice, but I have that in vim. I can run vim in the dev instance I'm ssh-ed into (which is 99.99% of how I work, anyway -- my work laptop is ancient and they won't replace it). I just can't see what those tools add, even for very large codebases.

My configuration for vim began in the 90's. I've never put that much work into it at any one time, though it has grown quite complex over time. There are a bunch of plugins I use manged in the config file. 90% of the functionality I need works without those plugins, but even when I need to install them from scratch it's easy to go from "scp config file over" to "full setup" with one command.

So in summary, I use vim because it's part of a larger set of standard unix-y tools that are heavily ingrained into muscle memory. The biggest advantage of vim in many ways is that it's a relatively rich environment (e.g. linting, syntax highlighting, doc hints, etc) that I can ctrl-Z to immediately be back in the terminal with. Other than that, it gets out of my way, and I don't think about the editor at all, I think about what I'm doing (decades of muscle memory helps a lot, though -- I'm incapable of not using vim keybindings to edit code, I think).

I should move over to neovim, but mostly haven't yet. That's more due to a couple of weird plugins than anything else, though.

dm319• 4 years ago

Leave me be in the terminal where I have everything I need at my fingertips as fast as I can think.

People talk about vim nit being an IDE, but I think a lot of people think of the unix command line as their IDE.

gkfasdfasdf• 4 years ago

neovim/vim are lightning fast, and since they are usually installed on remote servers as well it is nice to have a consistent experience editing files whether I am working locally or in a remote shell somewhere.

ar_lan4• 4 years ago

why you chose it over VS Code

VS Code has always felt clunky to me. It always felt like a halfway house between the speed and simplicity of Vim and the maximalism offered by JetBrains IDEs. I also just generally don’t love GUI apps for code because I desire to be right in my shell.

NeoVim offers LSP, Tree Sitter, DAP, and easy extensibility to reach full parity with any IDE, but with the benefit of it being:

* Faster (both in processing speed but also in my workflow). I can navigate significantly faster in Vim than I can in any other editor. * More familiar, to me.

I can’t speak to Helix as I’ve never heard of it, but in general, the Vim community is very strong and long-lasting - it’s been a top tier editor for the past few decades and will likely continue to keep that place (albeit NeoVim is the currently favored flavor for me).

Beyond that, the extensibility of Neovim is unmatched in VSCode.

I also do most of my development in a VM and VS code remote shell is significantly slower for me than just ssh + neovim.

huge amount of work, hoop jumping, and fragility to reach parity

This seems inaccurate. Maybe it’s because I use NixOS but my editor experience is literally the least fragile piece of software I use. I’ve ran into far more issues in both GoLand and VS Code than I have in Neovim. Perhaps because Neovim is less of a walled garden?

It took me about a weekend to properly learn Lua and how Neovim works, and after that, I was set.

spent months tweaking

I don’t know what process you took, but properly learning the tool from the ground up and minimally adding useful plugins as you go should not take much time at all. I don’t really touch my editor config unless I need to install a new LSP server - it always just works.

—

At the end of the day, the best tool is the one that enables you to be most productive. I find almost anything outside of the terminal clunky (the main exception is my browser).

modernerd9• 4 years ago

Thanks, some helpful insights here. (It sounds like the summary is, “set it up and don't fiddle with it too much.”)

I agree that the neovim community is great and neovim is of course very hackable, although there's always room to improve: an API for terminal UI would help a lot when writing neovim plugins and make everything feel more consistent, for example.

I don’t know what process you took, but properly learning the tool from the ground up and minimally adding useful plugins as you go should not take much time at all.

I built a neovim config from scratch, used built-in docs, community support, and well-known extensions when needed. I wrote small Lua plugins when I couldn't find extensions or workflows that worked for me. And I had fun doing it!

I got something good in a weekend, something very decent in a week or two, but still had a lot of gaps between what I had and what I wanted (session save, restore and quick switching; a Magit-like staging and forge management UI for GitHub CLI -driven PR management; invoking and managing long-running terminal processes from the editor; find/replace in large numbers of files across big projects with something more intuitive than a quickfix list; linting with something lighter-weight and easier to configure alongside LSP servers than ale; quicklists for LSP issues; a simple test runner with quicklist for errors; I can go on…).

After trying out extensions for some of those things but finding nothing that fit the bill, I played with Emacs and had a pretty similar experience there (weeks of work just to reach parity with VSC+a few extensions). I concluded I was wasting my time — it was pretty clear I was after an IDE more than a text editor at this point. VS Code seemed a nice in-between option. There are things I miss from vim/Emacs (speed, keyboard-driven workflow, getting to enjoy and celebrate editors with a community of likeminded weirdos), which is why I tend to get sucked in by these update announcements and discussions. But for the most part VSC is fine.

OkayPhysicist• 4 years ago

For a perspective that hasn't been shared all ready, I like modal editing because I A) don't like to use the mouse any more than I have to and B) have awful memory when it comes to complicated chords of keyboard shortcuts. Except for the bare basics (switching modes, jumping to the start and end of lines, etc), I heavily rely on much easier to remember names of commands to interact with my editor. Like toggling line numbering: I'm sure there's some ctrl-alt-F4 esque chord to do it in VS Code, but that'll be much harder for me to remember than :set number.

For similar reasons, I prefer the command line to GUI-based applications, that all seem to be built around either a love of clicking through a long series of cascading menus, or memorizing obtuse shortcuts. TUI applications like Vim integrate much more readily with my other command line tools, so it creates a much more seamless workflow.

esclerofilo• 4 years ago

but that'll be much harder for me to remember than :set number

You could also do Ctrl+P on VSCode (or Ctrl+Shift+A on a Jetbrains IDE) and search for "line number". Command based interfaces are no longer unique to CLI tools.

dadoomer• 4 years ago

I've found the extra complexity of IDEs unecessary and detrimental to my productivity. I like to keep it simple: neovim with LSP and fzf in a tmux session.

tiffanyh• 4 years ago

https://v2.onivim.io

I was always bummed OniVim v2 didn't take off.

It was a native IDE but fully supported VS Code plugin system.

jesperlang• 4 years ago

Why? Here are some reasons in no particular order!

* +20 years of muscle memory

* Total customizability, when you get good at configuring and writing small scripts it feels like you can do anything. VSC feels like it's all about plugins

* On the fly remaps. E.g writing latex and quickly add insert mode remaps for things you are currently writing about ":imap CO2 $CO_{2}" for a prettier version of CO2 as you type. Playing around with Zig? With ":map ,t :w<CR>:!zig test %<CR>" you can type ,t and it saves and tests the current file.

* Write simple scheme files for pattern matching with Treesitter to conceal unnecessary clutter in some programming languages

* Snippets, other editors have this as well but with Luasnip I program every aspect of how it works exactly as I want it

* Even with a bunch of plugins it starts in less than 100ms

vlunkr• 4 years ago

What exactly is fragile about vim/neovim? I'd argue that they are incredibly stable, being as old as they are.

For another point I don't see being brought up, I love the .vimrc file. You can version control your entire editor config in one file. Other editors tend to spread config out across different files (one per plugin for example).

I've had to spend time configuring every editor I've used, but all that time is tracked and documented in vim. I can have everything set up instantly.

fishywang• 4 years ago

vim, or at least vi, is something you can pretty much expect to be existing on any system you ssh into. If you are comfortable with vim, you have the editor part sorted no matter what system you are dropped into to debug/whatever.

dmix• 4 years ago

I was a Vim user for a decade+ and recently switched to VSCode 100% because the Typescript integration is unmatchable, no matter how hard you try in NeoVim (and I tried hard).

If you're a front-end dev there's really nothing better. Also the https://www.tabnine.com/ integration feels like magic, it predicts the next block you're going to type with scary accuracy. I'm excited to see where AI IDE integration goes.

But I still hate how VSCode is like a browser that will grind to a halt if you install (or misconfigure) too many extensions.

goffi• 4 years ago

- I have used vim for many years (15 maybe?), and once you have passed the initial learning curve (not so terrible, after you keep learning cool stuff even after years of use), it's useful for everything with the same shortcuts. I would actually spend more time learning something else like an new IDE. At the end, I have probably saved a lot of time by sticking to (neo)vim instead of following the latest trend.

- I like terminals because there is nearly nothing disturbing you, and it's usually quick to have something

- there are many little features that looks like nothing but are really really useful when you use them. I'm a big fan of C-a / C-x to increment / decrement a number, coupled with https://github.com/nishigori/increment-activator it's super useful (to change a boolean, a date, a number, etc). The "." to repeat last command, the "*" to search what is under the cursor are other great features. An occasional macro made with "q" may save a lot of time when you need to do a repetitive task, for refactoring for instance, and you can even repeat them according to some patterns with ":g". I'm not sure if those features have handy equivalents on other IDEs.

- I didn't spent that much time doing my config, just adding little changes here and there when necessary, over the years I've got a environment really adapted to my taste.

- I'm currently doing mostly Python, and vanilla (neo)vim is normally good enough, but I'm using Coc (https://github.com/neoclide/coc.nvim) for a little while, and it add a lot of helping stuff easily. Pyright + snippets are useful.

- when something cool happens somewhere else, you often have somebody adapting it to vim. I can use snippets and emmet which are occasionally very useful.

At the end, I don't feel the need to change, it works well, and over the time I could add some neat features to improve it (snippets, emmet, CoC, tagbar, etc). I'm not sure if changing to something like VScodium would worth the time to learn something new (and I like working with terminals).

agency2• 4 years ago

I use VS Code for my day job because I can't be bothered to sink that much time into configuring my editor these days. But I recently setup NeoVim to play with Clojure since the most popular VS Code Clojure plugin (Calva) interacts poorly with vim keybindings. It was surprisingly easy to get setup (used the Conjure plugin) - NeoVim has come a long way in the years since I had last played with it.

bee_rider2• 4 years ago

Yeah I don't see why one would try to reproduce the VSCode experience inside vim or whatever.

Vim or neovim inside tmux are really nice, though. You can just use the normal general-purpose linux ecosystem rather than learning an IDE.

denvaar• 4 years ago

Average joe-schmoe Neovim user here. My goal is not to emulate VS Code and other similar software. I enjoy Neovim for programming mainly because...

- First and foremost, I love the text editing features Vim has (eg. the movements, modes, keys etc). It just feels great on my hands.

- It's minimal. Well, you are free to make it as minimal or as bloated as you would like to ;)

- For me, it sort of gamifies text editing. I don't claim that using Vim makes me x-times more efficient at programming than someone else, but I do enjoy the thrill of learning a new, quicker way to make some changes.

- Vim/Neovim offers me a seemingly endless amount of things to learn. Some may see this as a negative thing, but I see it as a feature. It's truly like a skill or a hobby. You can learn the basics and be perfectly fine, but you can also dive deep into more ways to improve. I love this.

- I love how configurable it is, and also that you can actually learn about how it works.

- Also if I'm being honest, I feel like a myself and a lot of other Neovim users are basically masochists to some extent.

modernerd9• 4 years ago

Agree that it gamifies text editing – vim motions are fun, even though I largely don't miss them in VS Code, or I use a vim extension when I do.

…myself and a lot of other Neovim users are basically masochists to some extent.

It's great of you to say this, and heartwarming to see a sense of self-awareness on HN.

It's easy to rationalise our tech choices away (vim = speed, efficiency, freedom!). It's harder to admit that we may have chosen our tools simply because it's fun to walk a learning curve that runs sharply from pain to joy. Of course we could pick an easier tool! But then our path runs from apathy to apathy! And we'd be making it alongside people who think tools are just tools, instead of within a counterculture of likeminded people who think that tools are _everything_.

Maybe I should give neovim another shot…

alwillis12• 4 years ago

If you use Neovim, can you share why you chose it over VS Code

Every time I try VS Code, I get frustrated within 10 minutes and close it.

It’s a resource hog and the UI is kinda all over the place. The Vim plugin isn’t bad, but it only goes so far with the basic motions. It’s fine for basic editing but when you need to go deeper, it can’t go there.

I haven’t tried embedding Neovim yet, but that seems to be kinda of a hack. Besides I already have Neovim, so why would I embed it into a lesser editor?

But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed

I already have a Vim configuration I’ve been using for many years, so it was no big deal using it with Neovim.

I would also push back on the so-called fragility. I’ve been using Neovim for a 2-3 years and it hasn’t crashed once and I’ve done a lot of experimenting. In fact, I’m pretty impressed how well the many different plugins all work together. For example, I use the Tokyo Night colorscheme and it supports a bunch of the standard and 3rd party plugins by default:

* TreeSitter * LSP Diagnostics * LSP Trouble * LSP Saga * Git Signs * Git Gutter * Telescope * NvimTree * WhichKey * Indent Blankline * Dashboard * BufferLine * Lualine * Lightline * Neogit * vim-sneak * Fern * Barbar * Scrollbar * Mini

In a way, it’s not new—lots of old-school Vim plugins I’ve used also work great with the rest of the plugin ecosystem.

Vim was designed from the start to be part of a rich development environment. An IDE typically is a monolithic application; Vim and Neovim are designed to work as the centerpiece of a system of applications used by developers where they can use the best in class utilities as extensions to Neovim.

Vim works with linters, compilers, extensions, command line utilities and has done so for decades--and that was before Treesitter, LSPs and being able to be embedded.

BeetleB• 4 years ago

I know you asked for Neovim users, but as an Emacs user, I'll respond:

If you use Neovim, can you share why you chose it over VS Code

Who said you can't use both? Neovim is a text editor, and VS Code is an IDE. There is overlap, but they serve different purposes.

I use Emacs because it has a lot of capabilities that make little sense in an IDE. I don't think many people use VS Code for reading email, for example.

And I use VS Code when it's more convenient than Emacs (e.g. debugging).

kgarten• 4 years ago

Neovim user here. I also use VS Code and especially the Jetbrain products for IDEs. Yet, Neovim is for me just an editor.

- I like I can use the same editor on any platform. I'm a wearable computing nerd having several HMDs and small devices (devterm, raspberry pie, etc.).

- If it's my own platform, it's easy to compile it. It runs in a console and most of my plugins work on embedded, desktop and server systems. (could even compile it and use it on my hacked google glass .. with a twiddler one handed keyboard :D ).

- I like the use of keyboard-only and mode switching. It's more an hobby than anything else. I also use qtbrowser and Nyxt.

Also growing up with a very different Microsoft ("Linux is evil communism"), I still feel uncomfortable using VSCode.

jez• 4 years ago

As a Vim user I particularly liked this tweet thread on the topic recently:

https://mobile.twitter.com/hillelogram/status/15676069643974...

The central point of the thread was that VS Code is designed to be extended by dedicated editor extension developers while Vim is designed to be extended by basically all users of Vim. There are tradeoffs to both approaches.

gorjusborg• 4 years ago

What are you attempting to do with all that config hacking? I've used vi variants for years with pretty much the defaults.

I also use vscode and other IDEs. Why make it seem like one has to choose? That's like saying 'why do you use a hammer, i like screwdrivers better'.

AmpsterMan• 4 years ago

For me it's simple. My hands are already on my keyboard, and I already have my terminal open. For most of my programming I use whatever Jet Beans IDE my company has licenses for.

dislikedtom1970• 4 years ago

besides being efficient text editor, I must say it's also a hobby for me. I just enjoy endlessly configuring it and writing little vim scripts.

ZeroGravitas• 4 years ago

I use Neovim because I used Vim before it.

I used Vim because every GUI editor was an ugly, siloed proprietary mess that was mostly just wrapped around a bunch of open source command line tools, while Vim was an ugly, open source, programmable mess that was mostly just wrapped around a bunch of open source command line tools.

musicmatze• 4 years ago

If you use Neovim, can you share why you chose it over VS Code, or one of the new terminal-based editors [...]

I am using vim/neovim for almost 15 years now. I was introduced to vim within _days_ after I started programming. I have a workflow where I open and close my editor several times per minute (although I'm now slowly moving away from this workflow) - startup speed matters a lot for this, of course. I never bothered to learn another editor or IDE because of the speed I get with (neo)vim. Moving my hands away from the homerow for interacting with IDE features just feels like driving a Porsche in a 10mph zone. I have muscle memory in my hands for over 10 years now!

I switched from vim to neovim at around neovim 0.5 mostly for ideological reasons, but I stayed for lua based plugins and a IMO better community. I rewrote my complete neovim configuration (which I took over from vim of course) about a month ago to be pure Lua and to be more streamlined... I don't consider this work or hoop-jumping at all, but optimizing my editing environment to safe time when actually editing source code (or emails fwiw).

On a side-note, I also use vim-ish bindings for everything else, for me DE/WM, Email client (which uses neovim to write emails actually), etc etc. I just don't see a point in un-learning all this.

wyclif2• 4 years ago

For me the reason is mostly because of the speed of editing in Vim for me is blazing fast compared to what I can do in VSCode. Many of the most-frequently used Vim commands are just baked into my muscle memory at this point.

mikl• 4 years ago

If you want to use Vim keybindings for the whole experience (not just the text editor panes). VSCode has plugins for Vim-editing, but not a complete experience. Helix has similar, but different bindings. Zed is still in private beta mode, so no idea what its like.

There’s others, too, but none seem to have a big and healthy community like (Neo)Vim.

renox• 4 years ago

Nice customisation, but it still doesn't have the 'list of tab' vertical window that VSCode has, and I'll never switch to an editor which doesn't have this. Even if I find VSCode not very responsive..

zetaposter• 4 years ago

A text editor without a well rounded GUI story isn't worth it for me. There are all these desperate projects each with their own focus, ranging from "simple graphics acceleration" to "tons of bells and whistles, animations and ad-hoc UI extensions".

UI should be thought out at PRs and issues, but the same people who develop the main core. But they don't have to, because they're making a terminal application, which has its use cases.

But I so no reason why I should type my text in a terminal, when I can use a proper GUI application.

And I'm not even suggesting VSCode, even Emacs is better in this regard, which is what I use.

xwdv2• 4 years ago

The terminal is superior. You are just not skilled enough or advanced enough in thought to imagine what an interface can truly be.

sja• 4 years ago

Is this a sarcastic remark? If not, this seems like an extremely reductive stance. Surely one could imagine another skilled person preferring a GUI over the terminal, even if it's not an opinion they share :)

SuperCuber• 4 years ago

Your terminal application is an emulator of a decades old technology originally used in physical consoles, with layers upon layers of enhancements that add support for colors, cursor control, etc. At it's core, it's just a grid of characters. The GUI as a platform is quite literally a superset of the terminal, for example because the terminal emulator app is a GUI itself. Hacking the grid of characters to render lines as if it was a GUI is hardly "superior".

I say all that as an avid neovim user myself by the way. On mac/linux I use it through the terminal, on Windows I use it through the QT application.

mh7• 4 years ago

A real terminal or a fake one drawn ontop of a gui emulating deacades old cruft?

Complete madness and inefficiency.

andrewcl• 4 years ago

Do you have any refs/links of UI thought out at PRs and issues that you think are good examples?

gregwebs• 4 years ago

One of the main features of NeoVim over VIM is that NeoVIM can be embedded into other programs and new GUIs can be built that use libvim. There are now programs you can download that do that, for example [1]. Certainly, this is still an experimental line of software and I don't use the NeoVIM GUIs and don't claim that this has been proven a success yet, but there are some encouraging signs.

https://github.com/topics/neovim-guis

alwillis12• 4 years ago

I’ve used a few of the Neovim GUIs; they each have a different take on UI/UX for a Neovim GUI.

I’ve been using VimR the longest, which is a Mac-native GUI for Neovim: https://github.com/qvacua/vimr

scombridae• 4 years ago

By vim user count alone, I would conjecture that the venn circle of philosophically opposed devs has more people insisting on the absence of a GUI story, than those insisting on one.

Of course the vast majority of devs use whatever suits them, GUI or not.

And you couldn't have picked an editor with a worse GUI story.

sophacles7• 4 years ago

You're right. An environment that's all text and generally uses fixed width fonts is not at all the proper place to run an editor for dealing text that is best understood by displaying it with fixed width fonts.

zwkrt• 4 years ago

A text editor without a well rounded GUI story isn't worth it for me.

ed is the standard text editor.

https://www.gnu.org/fun/jokes/ed-msg.html

imbnwa• 4 years ago

Must every neovim release thread be brigaded by naysayers asking the same question for the 1000000th time? If you don't like its value proposition, don't use it. Simple. Keep using your IDE or whatever solution you prefer. This is almost exclusively happens in (neo)vim threads, and its so utterly distracting. That there is an entire community camped around neovim should answer your question about why anyone choses it over {insert non-vim solution}

gnubison• 4 years ago

But then what would we talk about? The update?

pacetherace• 4 years ago

I feel the proliferation of plugins has made the whole vim/neovim echo system too complicated and overwhelming to adapt for a new user. 1. Vim itself has a learning curve 2. There are many great plugins, but if they don't work for you, then unless you are an advanced user, it is impossible to get everything working without wasting a day 3. I find it weird that to get a vim plugin to work, I might have to install llvm and do a compilation and prey that all the dependencies have been satisfied

mekster• 4 years ago

What's bad is that while neovim tries to make vim much more functional with bunch if plugins, they barely stay stable.

I don't know why but even if I install same plugins with same config on various machines of same Linux distro version, some just throw errors on every launch while others tend to work and it's getting to the point of annoyance to keep using it.

It does feel like it's piling up parts hoping they don't fall apart.

Using vs code with remote config does make it feel saner.

gillh• 4 years ago

We recently started providing standardized neovim centric dotfiles setup to developers at our startup and this setup has improved productivity quite a lot.

Our neovim "distribution" is highly geared towards our tech stack (Golang etc.) and provides fzf based command palette.

See: https://github.com/fluxninja/dotfiles

We aren't using neovim's built-in LSP as we found it to be a bit immature. Instead we are providing coc.nvim.

andrewla• 4 years ago

I've been a Neovim user since inception -- I love the sane default configuration, the pruning away of old and obsolete "compatible" mode things, and the async and terminal support were killer features. When LSP support landed I was pretty firmly set.

I hate Lua, though, and more and more of the neovim ecosystem is moving in that direction. And now that vim has caught up on the async and terminal and LSP support I'm finding it hard to justify staying on neovim, except for the burden of sane-ifying my configuration.

VimL9 looks fantastic though -- VimScript has always been awkward but very domain-specific; VimL9 moves away from awkwardness but keeps the domain-specificity. Lua is not domain-specific enough, and the debugging and documentation are not good enough for me to pick it up in a pinch.

I think it's likely that I'll be making the switch back to vim9 in the near future, although I'll probably give Kakoune a try again before committing.

psalminen• 4 years ago

I use vscode and neovim. Both have their benefits.

Neovim is my main driver for reviewing/editing code. I have a few plugins and many personal functions/key bindings.

Vscode is great for quick copy/paste text and their plugin ecosystem. Ie working with azure has been a dream with vscode.

legends2k• 4 years ago

Congrats on the release!

Long live simple, non-proprietary, open editors which can be extended infinitely: Emacs & Vim (and their derivatives) FTW.

Neovim 0.8 Released

Related Stories