The client-server part is the one I'm most excited about. It is one of my favorite things in kakoune and it'll be nice to have it on neovim too. I find it more intuitive to use separate terminal windows with all the usual window manager shortcuts, instead of using vim-specific terminal splits.
Do the kakoune and neovim keyboard shortcuts conflict for you? I've put off trying non-vim modal editors because I think there's only enough room for one set of shortcuts in my head. How difficult is it for you to switch between them?
It's not too bad, because the most basic commands are about the same. The ones that get me the most are dd and V. When I switch to the other editor I get these wrong a couple of times before the mental model readjusts. That said, I never was a super advanced vim user because I couldn't remember the rarely used motions. Part of the reason I started using kakoune is that I find it easier on my brain. Basically everything is in Visual mode by default, where you select before issuing the command.
I've been using vim (neovim) for more years than I can count, but there is still so many movements that doesn't stick in my head, probably because I don't use them so much.
I recently came across the which-key.nvim (https://github.com/folke/which-key.nvim) neovim plugin, which helped me a lot to speed up finding what movement I want to do. It basically shows you a popup with what combinations are possible after you press any key (while nvim waits for the next one), so you can basically explore commands by just pressing keys, instead of having to look them up.
This is neat. I'm the type that immediately disabled the arrow keys when I was learning vim and treated it like learning the piano (which, I admit, is a bit mental) and just forcefully drilled most of it into muscle memory.
I think this would have sped me up even more. Definietly neat. There's also a few plugins/configs around highlight as-you-search worth exploring. That being said I strongly recommend against going plugin shopping, you only need precious few. It is a better use of your time to do it the hard way sometimes.
It's always fascinating how differently people read the same text.
I was just here browsing comments about the python2 drop after noticing the headline of the changelog:
> BREAKING CHANGES
> Support for Python 2 is dropped. For Python 3, the minimum supported version is 3.6. Legacy :pythonx commands are still available, and always uses the python 3 provider.
> One use case for the new remote functionality is the ability to open files from the embedded terminal emulator in the primary Neovim instance, rather than creating an embedded Neovim instance running inside Neovim itself.
Hmm, if I type "git commit" within the terminal, is there some value of $EDITOR that would make it launch a buffer to edit the commit message, then finish when I close the buffer? (and if so, are there distinguishable success vs failure ways to close the buffer?) That's my biggest editor-within-an-editor moment.
For that to work, you'll need the 'wait' versions of the remote flags. Those are still being worked on in a PR, but I'm hoping to finish them up by the next release: https://github.com/neovim/neovim/pull/17856
That said, this sort of remote opening has been possible in Neovim since the client-server stuff was added in the early days. This is only adding the remote editing flags and implementation to Neovim itself to make it easier.
That's a separate nvim instance within the terminal of the outer nvim instance. If I'm understanding this feature correctly, the idea is that instead of that, you make the outer nvim instance do stuff. Then pasting back and forth between buffers works better, etc. It wasn't clear to me from this short blurb though if that includes blocking for the buffer to be handled and then signalling success or failure to the caller. (or for that matter if I'll remember the mechanism for it if there is one. I operate on muscle memory and might just stick with the tiny editor within the bigger one. But I'm curious anyway.)
It could even overlay the terminal pane for the duration of the command with the buffer pane. So it'd look a lot like opening the second editor instance, except incorporated with the first editor's buffer list, registers, etc.
Does the new filetype.lua script still run the ftdetect/ scripts? Or will those only be run by the filetype.vim fallback and need to be ported to the new system?
I will never understand why people choose VSCode/Jetbrains over a terminal based editor. I can edit the kernel with clangd and get hover reference, autocomplete, go to def, ref, dec, smart refactor, and that's on top of being able to easily jump and fix lint/bugs using Vim's already great support for parsing compiler errors. With term added (which is a core Vim feature) it also has excellent support for gdb debugging. I am very glad that neovim is also making things EVEN BETTER with tree sitter and baked in LSP support.
So I get 98-100% of what an IDE gives me, I can use my editor over ssh and edit anywhere, I don't need a GUI to even be installed on the system where I have all of my cores and RAM for compiling the kernel, it starts up instantly, and it's completely free and open source, not driven by a corporation, and there's decades of documentation on how to use it.
Edit:
I really don't understand the comments of "I will literally not spend a single minute configuring my editor". I guess it's the systems developer in me that can't fathom someone that wants to use a tool to make a living without understanding it fully and being able to tweak it to their exact liking over the course of their entire career.
I personally consider my investment into Vim one of the best I ever made. If dumb college me can do it in a few weekends, you can do it. I recently setup Emacs and got it to the same level as my Vim usage in about two days of tinkering just for fun. Then again, I suppose some people are just here for the money and want to clock in and clock out as fast as possible. I really wish I could share with you the joy of tinkering, learning, and growing your knowledge about how these wonderful machines work.
> I will never understand why people choose VSCode/Jetbrains over a terminal based editor.
I don't want to use my valuable time learning how to get vim working in some super-optimal way that's hypothetically going to improve my productivity by 1%. JetBrains consistently works well enough for me that I'm not going to bother switching. 90% of my life is spent thinking about how to solve the problem so the editor is not the main constraint.
The promise with Vim (and Emacs) is you'll never need to switch to something else, and the skills are transferable (script with Lua, keybindings very often available in other apps). Interestingly it has helped me most with cli stuff, I can edit command lines much quicker and have even configured a keybind my shell to open the command line in Vim for editing.
If a terminal-based workflow is not your thing it's a tougher sell.
> If you're a lifelong programmer the time it'll take to be proficient in Vim is a drop in the bucket in the grand scheme of thing
I just don't see it? I spent a good 6 months only using vim to see if I could get it to stick. Then I took a year break. After the break I forgot nearly every shortcut I was using minus a select few. I never got to the point of even matching my efficiency in other editors, let alone surpassing them.
6 months alone is already more than what I would consider worth in regards to time spent learning a tool for the little gain I see it bringing over just using intuitive, albeit less efficient, alternatives.
I mean, it's kind of expected to forget about them if you took a break for a year after having used it for 6 months?
I do think 6 months should be enough to see some benefit in your workflow (like ci" to delete everything between "" and go into insert mode or Ctrl-O to go back to the last place you jumped from).
But I guess it depends on how you practiced, and if you look at those 6 months I'm sure you'll see that the time spent on actually learning Vim (struggling to learn these efficient editing patterns) was much less than you'd think.
With a tool like Vim I don't think it's enough to just use it, but we need to put conscious effort into it to learn it properly.
I spend most of my time inside a terminal and have my shell configured so line editing is as much like Vim as possible. Also configured Vim modes everywhere else possible.
Also, although historically that hasn't really been part of the Vim ethos (compared to Emacs at least), you're expected to mold your editor over time to suit your needs exactly.
If you value your time that way, you should re-consider (neo)vim. I learned vim in the late 90s. I still have stuff in my config from that time period, that still just works. It's an up-front cost yes, but I see it similar to a carpenter learning to use a hammer - it's a skill that carries forward for at least a quarter century.
In the same time period, I've watched plenty of my cohort jump between IDEs and "modern" editors as they come and go (jetbrains, visual studio, textmate, sublime text, vscode, the various storm ides, etc etc). They all have to put time and effort into getting comfortable and proficient in each of these environments. That time adds up to be more than my initial vim investment.
Now I'm one of those folks that likes to master my tools and craft my own tools as well, so I've continued to invest time in my vim mastery. The same argument applies here too: that time is cumulatively increasing my skill at the tool rather than getting to the same point with various tools (cf the old interviewing dilemma: does this person have 5 years of experience or 1 year of experience 5 times). It means that some years I don't spend any time thinking about my vim setup, and other years I'll throw a few hours at it - importantly, this happens when I want not when the tool decides to release a new version that breaks things, not when theres suddenly a new great thing I have to use to keep up.
In summary - from a time/effort efficiency point of view for the course of a career: vim wins because the tool was there when I started, and its still here long after the "better" alternatives have come and gone (or faded into obscurity).
I'm a dev that spends 90% of his computer time with a JB IDE open and I'll give you my perspective on it. It just works out of the box (or with a couple of 1-click install plugins) for practically all my use cases.
* I mostly write Kotlin/Java for backend, desktop and Android projects. JB has that covered: Gradle integration, refactoring, navigation, dependency updates, documentation viewer, visual git log/diff/merge/rebase/blame, visual Android layout editor, visual JavaFX/Swing layout editors, run configurations, step through debugger that shows current variable state on top of my source code, all the android resource/variant stuff, test runners, trigger tests from source code, tool windows for docker (compose) or other services and probably much more.
* I do C/C++ development on some projects in Clion which has most of the stuff from above but :s/Gradle/CMake/g.
* Aside from the above I also use my IntelliJ Ultimate for Python, Ruby, Golang, Rust, Markdown, Mermaid graphs, Kubernetes yamls and Terraform hcl files, Lua and probably some more. All with the excellent IdeaVIM plugin so I have my modal editing and ex commands.
I gladly pay $600/year for all this. If I have to spend one day (likely more) on configuring vim/nvim to even do a subset of what I mentioned, then JB is cheaper.
So, that is why I switched from years of Vim use (and a couple years of Emacs before that) to JB and I haven't looked back. I don't see why I should artificially limit myself to vim/terminal only when JB+IdeaVIM gets me the best of both combined.
Purpose built tools like jet brains IDEs are super nice. What I like about an OSS terminal based editor is that all of the languages, frameworks, etc you listed above may change in the next 10 years. Or 5 years. And again that many times during my career. I'd rather not have to retool each time that happens. I like being able to jump into some area thats new to me, like data science or graphics, and have my existing tools just work (other than proprietary stuff like iOS dev).
True, it was like half a day of extensive coding for the basics, a bit of cursing, then about two weeks of settling in and then a few hours over a couple of months, when I did heavy extension and configuration.
Bonus: my window manager has similar keybindings these days
Yes, do it this way. When I learned vim, I just went to work and decided to use it one day. The only thing I did was get on Stack Overflow and look up how to turn off the arrow keys, so I would have to use hjkl.
As you said, by the end of the workday I was very comfortable with basic vim use.
I absolutely want to learn VIM but saying it's only a weekend is plain misinformation. We're definitely looking at months of gradually building new habits.
Agree, and I would add that it's not just habits, it's committing to rearchitecting your workflow. Do you use things like debuggers, linters, refactoring tools, project management tools, etc.? Get ready to learn totally different tools (usually)!
I'm a committed (neo)vim user, but I readily admit I only got over the hump because I thought it was cool and hardcore and typing is easy for me. There's no question it's been worth it for me, and I would argue it's probably worth it for most people and better for the software ecosystem as a whole (GUI tools don't compose), but still I think trying to say one's better than the other is too narrow a view.
The basics are very simple. You just get used to formulate a (weird) sentence of what you want to do in your head, abbreviate it and then learn (or configure) the buttons.
The problem here is the "just" word. To you it's "just" (as in a day or two), to me it's "I have to learn to think in a new way and that will take a while".
You don't need to be super-optimal to use Vim. I've used it for decades and I don't care about being optimal or what to "save effort" in terms of efficiency. I use it because I like it. :)
I think you can be productive in an IDE. But when it comes to vim (have been a vim-only user since 2013-2014) there is not a comparison really.
Every time i do pair programming, i always get the "wow how did you do that?!?" response. It's just SO much ahead of an IDE in so many ways. Modal editing (imho) is far superior to "just insert mode" style of text editing.
With neovim (and vim + coc before that) i get 95% of what an IDE could give me, and the last 5% (like some obscure refactoring stuff) is something is would probably never use.
TLDR. I think learning vim is like learning SQL. It's a cross language tool, that will massively benefit your entire career.
I could ask the opposite: why do people choose terminal vim when you can easily add nvim integration to editors like VSCode and get 98-100% of what vim gives you along with much easier configuration of all those extras you mention like autocomplete, hover reference, refactor, etc.?
That's a bit of an overstatement, because I really do love vim/nvim and nvim integration isn't that good, but the fact is that adding a feature in nvim still means researching and configuring it where in something like VSCode you open a new filetype, it asks "do you want support for this file", click yes and you're ready to go. I can spend a few days trying to get vim to work in the way I want it for a specific filetype/framework, or I can get 90% of what I want from VSCode in 30 seconds and still have vim navigation and command support.
I find Coc.nvim plugins for neovim are virtually just as easy to set up as VS code plugins, VS code is a power hog and performs worse, and the vim bindings are rough around the edges with macros in particular. VS Code with a vim plugin is not a bad experience, but neovim+coc.nvim is just much snappier.
That may be, but this is the first time I've heard of coc.nvim and I've used neovim for years. So I'll bookmark this and at some point I'll look into it and do some research and figure out how to configure it and compare it to competitors, but is all that really worth the very slight performance advantages we're talking about? I can't type 1000wpm after all.
Sure, VSCode is a power hog and it's slow, but I make pretty good money so the cost of a more powerful development machine is trivial compared to the opportunity cost of doing all that research. Some years I really enjoy learning all about new ways to configure vim/nvim, but I recognize that it's really not an efficient use of my time, it's just been something I do more for fun.
Yeah I agree about it being something that's done because you enjoy it. Talking about what's an efficient use of time is so strange to me though, not to single you out in particular. It's like we're pretending our lives are so hyper-optimized that everything is a delicate trade-off. I spend a few hours here and there messing around with my setup because I want it to feel nice to use. It's not like I traded a couple hours of productive programming time for that. Sometimes I spend a few hours watching a movie.
For me a snappy editor experience, and vim in general, is about comfort, not optimizing for some theoretical top editing speed. I don't think I'd be a drastically worse programmer if I were forced to use windows notepad to edit code, I would just be more uncomfortable all the time.
The 100% full reason for me was that I had a job where I needed to SSH into our prod server about once per month and tweak some files. I was so terrified every time I had to do it because I was afraid of vim and/or nano in those situations. So I decided to get competent so I trusted myself not to make huge mistakes.
After about a week of using vim it clicked and I knew I couldn't go back to Sublime Text.
As for VS Code, I do everything I can to keep Microsoft products out of my life.
> The 100% full reason for me was that I had a job where I needed to SSH into our prod server
Statements like this are common, but they confuse two usages: (a) learning vi/vim well enough in order to use it in any unix environment vs. (b) using vim with a complete plugin/config suite as a primary development IDE replacement tool.
The former is IMHO an essential unix skill, but it's incredibly inefficient to try to use core out-of-the-box zero-plugin vim as a primary development tool. But once you start configuring an efficient dev environment, the GUI editors start to really outshine vim, and they still provide core vim functionality via plugins if you want it.
That's a totally fair point, and I realize my comment wasn't really in the spirit of that original thread in the first place.
What I really meant to convey is that I dipped my toes in just enough to get familiar, and that was enough for me to get fully hooked on vim. I've spent lots of time trying to make Jetbrains/IdeaVim and VSCode/vim-plugin work for how I write code. Significantly more than I want to admit publicly...but I come back to the boring old terminal every time.
I am not trying to convince any person on this planet that they should use vim. In fact, when other developers at work ask me if they should try I say "No" 100% of the time. But Jetbrains/VSCode are a firm step down for my workflow.
You can use Sublime Text remotely though, just requires some effort to set up.
My issue with Vim is remote servers and containers never have my (awesome) config.
It still pays off to know some basic Vim keybinds. You can often use them in other applications and every once in a while some machine only has vi. That said I grew up with DOS, do ctrl keybinds feel natural to me. Its just nigh annoying switching from macOS to Linux given the position of ctrl/fn/alt/super are different.
vscode is open source, there are forks(vscodium) where all the microsoft stuff is removed and you can audit it yourself if you think its sending tracking data back
I used this combo for a while, but there was a period of time where VSCode updates would break the vim integration. This was a few years ago, and I’ve recently reinstalled VSCode for use with F#, since Ionide seems to work better than in Neovim.
> I can use my editor over ssh and edit anywhere, I don't need a GUI to even be installed on the system where I have all of my cores and RAM for compiling the kernel,
I launch my editor once a day. Why do you need to keep killing and starting your editor?
> and it's completely free and open source,
OK, so is VS Code, or at least the OSS version, which has all the key features anyway.
> not driven by a corporation,
So this is your philosophy.
> and there's decades of documentation on how to use it.
Most of it out of date, probably.
> I guess it's the systems developer in me
Guess what? I'm a systems developer too! I also work on the kernel! But I use VS Code.
> that can't fathom someone that wants to use a tool to make a living without understanding it fully and being able to tweak it to their exact liking over the course of their entire career
VS Code is open source, so there's nothing stopping me from diving in if I want to. And it's also highly extensible.
Now that I've answered all the supposed benefits you list about (neo)vim, I have one question:
Can (neo)vim show text in two different font sizes? Or fonts? Like, what if I want my documentation popups to show up in a sans-serif font? No, don't tell me I have to open up the documentation in a browser or whatever. I want it in the popup.
Same reaction but in the opposite direction. I still do not understand why some people are that obsessed to dedicate a large amount of time learning a software that will sometimes make their life a tiny bit easier in rare edge cases. Every time I try to learn how to use Vim as an IDE, I just end up massively overwhelmed and never even come close to reach a fraction of my productivity on VSCode. The fact I cannot see the benefit where others can is frustrating.
Most people I know that use Vscode now are coming from TextMate -> Sublime Text -> Atom -> VScode.
Meanwhile my Vim go brrrrrr :D
Seriously, there's a huge benefit to not constantly switching and learning new environments (admittedly since Neovim / switching to Lua for scripting Vim there's been a lot new but all things the community wanted)
Seriously, there's no benefit to sticking with one environment. The right tool for the job. If you're doing Java for instance, no version of vim or emacs comes close to the functionality of the popular IDEs. With vi perhaps you can type more efficiently. With a good IDE, you can develop far more efficiently. For modifying bash scripts on remote machines, vim all the way.
I could agree with you a few years ago but since LSP and Tree-sitter the tables have basically turned, I'm pretty confident you can get _more_ IDE-type features in Neovim (albeit with some amount of effort, no doubt). But, again, you can tailor that exactly to your liking.
> it is intensely gratifying to build and improve the world around you.
For many of us, we expect we will be spending a significant chunk of our lives in the text editor.
Picking a dumb, inert, fixed, limited text editor is an apalling choice to some, versus picking something that has rich means of working the system (text objects, spellcrafting on the fly!!!) and infinite possibility (that flexible configuring, leader keys of possibilities). Picking a starting point where more is possible, where building & growing our world can be done- it's a path of lifelong struggle, but immense lifelong gratification, one where we will see our world florusihing and ourselves growing within in.
I personally resist a lot of the configuring & addition of plugins, am only an ok advanced vim user. But Im pretty ok at writing macros when i have a shitty chore, i make use of registers to handle reusable text- I appreciate having something much closer to a programming language than a input box at my back, and i keep slowly improving.
One big benefit from my perspective is that due to being terminal based, vim makes it much easier to edit remotely and makes it relatively easy to bring your environment around.
While vscode's ssh option is cool, it still requires that you have it installed on your local machine and while the web based version doesn't have that issue, it's missing other features (like ssh).
So for me the biggest motivator for switching to nvim has been the ability to connect to my machine and work on code from any device (ie even android) anywhere, only needing access to a terminal, and if I need to work on someone else's machine, having my environment there is as simple as cloning a git repo with my .vimrc
I don't know why people would use a text editor in a terminal when they can use that same text editor as a desktop application.
Fonts are better, colors are better, it is faster, less latency, running a terminal inside your editor works better, pop-ups and overlays work better/are more flexible/easier to read, mouse interactions work better, resizing works better, it is easier to run multiple windows, it is easy to run multiple different fonts with different font sizes, etc etc.
I also don't have to figure out solutions to conflicts between the keyboard shortcuts between the shell, the terminal, the terminal multiplexer (screen/tmux/tabbed terminal emulator), and the editor.
> I can use my editor over ssh and edit anywhere
I can just have my editor use ssh to edit files anywhere. Remote editing is a thing.
Anyways for proper system hygiene you shouldn't be shelling into anything except to troubleshoot problems or for checking things you don't have monitors in place for. This is why we have things like ansible or puppet.
In fact the whole insisting on having an editor in a terminal emulator thing is probably holding Nvim back as a whole. Which is why you don't see the obvious benefits.
Since the community wants to use terminal emulators so heavily then all the add-ons and features of the editor must support the lowest common dominator between desktop apps and terminal emulator, which is almost always going to be the terminal emulator.
Just remember that you are not avoiding a GUI by using a terminal emulator. It's still a GUI. Just a GUI designed for running command line applications in a Unix-style shell. And Neovim really isn't even a command line application.
Thank you, I agree with this perspective. The content density from a professional IDE is higher than what I get from a terminal editor. I can't imagine tooltips using the same font size as the rest of my code. I don't like it when the UI elements use monospace fonts.
Integration. The last time I tried neovim the LSP kept crashing for me on random occasions, some plugins had considerable performance issues, some things weren't async, and so forth.
Vscode or Jetbrains or any other integrated software is from the ground built up to have its tools work together 100% of the time. I like vim fine if I edit something without any plugins needed but otherwise I'll stick with an IDE. And if I want vim controls I'll just turn them on the IDE because conceptually for me it makes more sense to port keyboard controls to an IDE than to port the entire IDE to a terminal
Practical example, look at the instructions to set up an ide-like ocaml environment with neovim[1]. It requires basically to install half a dozen tools by hand and to fix the linter config before you've even started. In VsCode it's literally one click.
> The last time I tried neovim the LSP kept crashing for me on random occasions, some plugins had considerable performance issues, some things weren't async, and so forth.
Any issues with the language server I doubt are client side, and every request/response is "async".
4. That will give you basic linting, you can add keybindings/omnifunc integrations by copying out our configuration examples from `:help lspconfig` or the lspconfig wiki.
We're not trying to target vscode users, so if the above is too many steps that is ok, you just aren't our target audience.
I made your same argument for years to a buddy of mine that always used WebStorm (I'm a Python dev and he kept pushing me to try PyCharm). A coworker pushed me to try PyCharm since we're on Windows and I haven't really looked back. I even bought CLion.
If you can point me to an easy debugger to set up in neovim I'd probably be right back, but I can't. Couldn't figure out how to set up vimspector. And in PyCharm, at this point, I find it has better tooling than coc (I haven't wanted to spend the time setting up LSP/treesitter).
Furthermore, doing development in wsl isn't that great in my opinion and native windows neovim isn't either, even when using Windows Terminal. Its slow when handling a massive repository. FZF with ripgrep still works massively faster than telescope for my main work repository. I mostly dip into wsl when I want to do complex grep/sed/find operations and to make edits to my hledger timeclock sheet.
But one thing I've found to be a killer app for Pycharm Pro: vim keybindings in jupyter notebooks. Works way better than the plugins for Jupyter Lab.
IdeaVim is sometimes kind of disappointing, I wish JetBrains would just add a neovim plugin (I want to use vim sandwich instead of vim surround but alas). Still, it's good enough.
I watched your first video. As someone who likes the idea of Vim and has learned many of the keyboard shortcuts, my impression of the video was "Debugging in Neovim is quite simple. Just remember these 35 keyboard shortcuts."
That's true, it requires a bit of memorization and configuration. I've put the shortcuts similar to character movements: CMD + j,k,l (jump over, jump out, jump in).
I've mentioned this to several others (and also as a response to David in the past) but I highly, HIGHLY recommend anyone who's just getting started with nvim-dap, watch these videos. They helped me immensely when I was first getting it set up.
Thank you David, they're a fantastic overview of these plugins!
I knew I'd watched the first two videos at some point because when I opened this page, those first two links were the only ones greyed out. Good stuff.
I've been a hardcore vim user since early 2000s. I've switched to VSCode a couple years ago and haven't looked back.
My .vimrc clocks in just below a humble 500 lines. VSCode gets me more with practically zero configuration out of the box; a few clicks to install relevant language extensions and that's it. It's more stable and more performant on large files (e.g. 2+kLOC Python modules). RemoteSSH and RemoteWSL plugins are 100% pure gold.
Vim/Neovim/Emacs/etc. require a certain "commitment" to them - you have to learn keybindings, for example. Moreover, if you want any fancy IDE features you're addicted to, like hints, autocomplete, static analysis, refactoring, etc. you have to configure it yourself, which still isn't quite straightforward as selecting a plugin in VSCode (perhaps this is a good feature idea?).
Most people just don't think it's worth it, when the existing tools are Good Enough for them.
But once you pass the initial obstacle, vim/emacs/derivatives are really nice to use, and there are plugins for literally anything out there.
Are people seriously training their muscle memory to the default vim keybinding that is so cryptic I don't know what to say.
Since the early days of learning vim, I've changed the "go to end of line" bound as "-" which is next to "0" for "go to start of line" which is way more logically placed than some "^" that even needs shift pressed.
If anyone thinks "because default works on any machine", you need to think how you're wasting your brain cycle on unnecessary complexity for no reason.
For me, "because default works on any machine" is a valid argument for some things and for others it is not.
jk = Esc is so crucial, I can not live without it.
Start of the line on the other hand is just `0w`, so not that clunky.
I guess it depends on how much time you are spending on what amount of different machines :)
These "muscle memory produces some weird result" vs. "this keybinding is not very convenient" also affect my thought process in different ways.
The first one disturbs me much more for some reason.
There's 0 configuring. It's as simple as installing one of the many LSP clients, like ALE, that will automatically detect and start a language server for you with the right arguments.
You and I must have different definitions of "0 configuring". There is no "one" LSP client, so every time I want to spend time training my vim muscle I have to research basically which one [is the best/has the most problems or users], whether the language server works well with it, figure out which plugin manager I should be using, write down and remember the shortcuts to invoke my plugin manager, set up key bindings, set some more configuration flags, then maybe have something working by the end of the day.
After all that, yea I'm more productive but I think the large barrier of entry to CLI editors is what keeps people using IDEs and their Electron cousins.
If that's true, I'd really like to try that. I've never heard of ALE, so thanks for that.
Still, the fact is that you have to know what to install. It's not like the NeoVim manpage mentions any LSP clients. So it requires a lot of tinkering, reading and participating in the community to figure out how to do stuff. That's exactly opposite of 0-configuring.
If NeoVim could bundle an LSP client with it, and have a config key to enable it, that'd be dope.
Of course :) Lspconfig adds an autocommand that does this for you when it detects the filetype, and includes the start commands (that's it, all the other functionality is in core.
Could not disagree more. For entertainment purposes, I've installed neovim with `brew install neovim`. Opened a small project with `nvim ~/projects/whatever`, and am presented with a screen full of errors (https://imgur.com/D0ydDIG). Pressing enter brings me to a blank screen with even more errors. It then drops me into a vim document with some modal screens and now now I'll probably spend hours researching what all these mean, why this is happening, etc.
All those features you've listed aren't anywhere on the homepage, how does one even do that? I'm interested in learning more, but to think one can do this in a weekend just isn't true.
While I'm sure I could figure out all these kinks, its just software, it's the time sink that makes me pause. I don't see the value here, but I also don't know what all it can do compared to my current workflow with VSCode.
I held this view too for quite a while. But in recent years as I’ve been exposed to some really powerful features in VSCode and GoLand, I’ve adopted a much more flexible workflow. I always have my CLI editor running and might spend the day in there, but I often have an IDE running in parallel (with Vim bindings, naturally). By now I automatically switch between the two based on whatever is the better platform for the immediate task, and have let go trying to load up Vim beyond basic LSP.
Neovim is amazing but recall how long it took you to get used to vim keybindings. It isn't something you master overnight. I recall it took me a few weeks to get comfortable. Lots of people are perfectly comfortable not using keyboard navigation.
Edit: Also to note - vscode supports editing files anywhere over ssh as well, so there isn't a huge advantage to neovim there.
Except that I can use vim on my iPad Pro with just a terminal app, which I can't do with VSCode. Vim is portable anywhere you can get a terminal connection, even if it's over serial.
If vim or neovim can work as featureful as JetBrains, I'll switch any day.
Let me know how to highlight SQL in strings and make tables linked to remote database over SSH and autocomplete table names and column names as I type. And make sure that its grammar is checked against specific RDBMS's available syntax.
And I also want code formatting that's not entirely opinionated, so I can decide what gets wrapped and what gets indented and let it format an entire folder with a shortcut.
And if I'm setting the project to use PHP 8.0, make sure to highlight features I've mistakingly used from 8.1, so that I don't get runtime errors.
And if I'm editing files over SSH, make sure that if the remote file is changed, it warns me before I upload a local version, so I don't accidentally overwrite any remote changes and give me the option to merge.
And for sake of being right, in PHP if I have a function paremeter set as a string, highlight "is_string" check on the parameter as redundant, so my code doesn't look dumb.
I probably have others and even more that I'm not even aware of from its feature lists that can be useful over what vim/nvim can offer after taking some months configuring it to my liking.
I suppose you're comfortable missing out on those?
I like using vim as an editor. I don't bother with janky plugins that require some arcane blood ritual to install, configure, and be invoked. I'm not going to go through the trouble of setting up vim as a java ide when intellij does that intuitively out of the box.
If I just need to edit a file, or view it, I'll often use vim. If I need to sit down and actually code? Intellij every time.
If vi had never existed, and you introduced it today, people would think it was some sort of april fools joke of an editor. It is the least intuitive and user friendly piece of software I've ever used. The only reason I continue to do so is because I've learned it's quirks and it's stockholm syndrome now.
> I really don't understand the comments of "I will literally not spend a single minute configuring my editor".
It's really not difficult at all. I and others have probably a million things we would like to tinker with (yes, including tweaking a text editor), but we all have a limited time so we end up with priorities. It just happen that I didn't make a priority to tweak vim/neovim because I'm happy with my current code editing setup. For other kinds of software, I may not be happy at all, to the point of writing my own.
See: different people, different expectations. Your choice being right for you doesn't mean it's the right choice for everyone. Tolerance 101.
Maybe because it’s all easy to find. You don’t need years of experience, just search for the plug-in you need. Sure it’s probably worse, not really portable and possibly insecure, but the barriers of entry are so low that it works great for most people.
Precisely this, kitted-out vim in the hands of someone experienced is a force multiplier but it's uh, 'late-game'. VSCode and the like take absolutely minimal brainpower and experience for near-enough similar gains (for most users, I would say).
I say this as someone who uses both the editors I mention depending on context.
I've used Vim for 20 years. My main issue is that, while I love the text editing part, setting up something aesthetically pleasing with IDE-like features takes a lot of effort -- especially when you're dealing with multiple layers of shell + iTerm2. Some even add tmux on top of that! My setup still doesn't look on par with the amazing setups I see on Youtube. There are too many low-level settings you need to mess around with and it's completely unintuitive.
Felt inspired to look at this again and there is a project called LunarVim which advertises giving you an "IDE" experience out of the box. Looks promising!
One of these days I really need to sit down and commit to learning to use Vim at this level. I always use Vim when I'm editing from a terminal but generally stick with VSCode or the Jetbrains family of IDEs for any real coding projects.
I've just never gotten around to learning vim in a more advanced way than edit, replace, copy paste, skip to line and search.
Any good suggestions on where to start? I looked at Spacevim but that seems to just throw everything at you.
It’s a pretty gentle introduction to vanilla vim over 4 weeks. After that point I’d recommend using nvim and all the plugins you want to make life easier, but learning The Vim Way is very powerful
I think it makes sense to start from scratch and learn new features step by step, otherwise it quickly becomes overwhelming. I made some videos on how to configure Neovim, maybe you'll find it useful: https://youtube.com/playlist?list=PLu-ydI-PCl0OEG0ZEqLRRuCrM...
For "base" Vim (pre-neovim), the Practical Vim book and Vimcasts by Drew Neil were very helpful.
To get the muscle memory, try blocking the arrow keys in your config or even hiding the cursor (I'm serious, I once had this unintentionally and realized that because I was so used to Vim movements I didn't even need to see the cursor in normal mode).
The vim way is: stay in normal mode, learn to move efficiently with searching, jump to char, forward/backward words etc.
Don't use a prepackaged config. Refrain from plugins until you know for sure what you want.
I prefer using (neo)vim, but I find it a bit disingenuous to ask such a question. LSPs wouldn't exist without the investments made in VSCode. I'm grateful for this technology aimed at bringing IDE features in any editor (instead of being silo-ed), and don't really care if most people prefer the comfort of integrated environments.
Question to those who are using both NeoVim and an IDE like VSCode/Jetbrains:
Suppose you're using VSCode/Jetbrains with proper keyboard shortcuts (stuff like expanding selection, search/highlight all matches, ...) - basically never using the mouse. Is navigating / editing with NeoVim really that much faster?
Just curious: you mentioned SSH. What is currently the optimal way to setup vim/neovim over SSH and carry all your configuration over with you to different servers?
I moved to Neovim from Vim based on the recommendation from my 16 year old :). He also suggested https://nvchad.github.io . NvChad was great in setting up the Neovim configuration with LSP for Ruby and others. Much better experience than Vim.
Thank you for the great video - I'm glad I watched it. Hadn't heard of Helix or Kakoune until now. While I have decades of muscle-memory in the vi key-bindings, it's easy to see that the select-object/verb method makes a lot of sense.
I switched from Kakoune to Helix recently. I've been very happy. It'll be a larger leap for a Vim user, but it was almost drop-in for a Kakoune user. Though i did tweak my bindings quite a bit to be more Kakoune like hah.
For me it was that it worked mostly just like Kakoune (or at least, the parts i used of Kakoune) with nicely integrated LSP. It also had TreeSitter based movement options and themes, which is really interesting too. A potential future where vim-like navigation is done on TreeSitter objects is attractive.
The potential DSP integration is nice too. And to top it all off, it's made in a language i enjoy and within the first 24h of using it i had a PR made for a small feature i wanted. Being able to contribute in a language i enjoy was nice.
I don't use either one, but just from reading the comments here: using treesitter for syntax highlighting and having LSP configured out of the box (for kakoune I think you need to install an extension called kak-lsp).
I installed helix a few days ago and I realised that I've been using my neovim setup with much higher input latency than I'd like. I'm not sure which plugin is responsible for the increased typing latency or if there's an easy way to find out.
I wish helix had a mode where its keybindings become the same as that of neovim for easier transition. After years of using (neo)vim, it's almost impossible for me to switch to a different set of modal keybindings. I always ended up pressing x to delete characters in helix which, in turn, ended up selecting the entire line.
I think currently Helix targets a different audience. Helix does not have a plugin system (there is an ~1 year old proposal to use WASM but until it is functional the point is moot) or embedded scripting language, so your ability to customize it is extremely limited.
Same here! It was the first project I helped funding, and been funding it for as long as they have allowed donations. The biggest feature for me is being able to use lua instead of vimscript for basically everything now. I never learned vimscript properly, and now I don't have to anymore either! Win-win.
What do you mean by "terminal sessions"? I use vim inside regular xterms or tmux. Am I using such terminal sessions already? What would be different in nvim?
Both vim and neovim have the ability to open a terminal in a window split. It's not my preferred workflow but some people really like it rather than tmux or ctel-z to drop onto a shell... the implementation of this feature in neovim is a lot nicer than the one in vim.
One thing i do use it for: In neovim there's options to open the terminal as a sort of overlay on top of the existing splits, they call it floating term. Its really nice for opening tools ( e.g. lazygit or a test runner) because find it a bit less disruptive than having to bounce in and out of the editor by other means.
# Enable vi mode
setw -g mode-keys vi
# Copy to host
bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi y send-keys -X copy-pipe "pbcopy"
unbind -T copy-mode-vi Enter
bind-key -T copy-mode-vi Enter send-keys -X copy-pipe "pbcopy"
It mostly work as expected, ctrl+B ] enter copy mode, then you can use / and ? to search, v to enter character visual mode, V to enter line visual mode and y/enter to copy the selection.
Because running tests doesn't necessarily play nice with quickfix?
I do set the make program to build and get errors via the quickfix when there isn't a good lsp server for the language. When there is an lsp server for the language, why bother with a special make command? - the same info is just populated inline for you.
I tend to use quickfix lists because I can edit/filter/persist them; so for example I'll have some tests/warnings but won't care about them for the moment but then rerun the command and get the diff and navigate to that.
It's fairly complicated to script the same using the LSP api.
I mean the buffer with a shell that opens when you type:
:term
I remember vanilla vim doing some weird stuff, like leaving the buffer open even though I've exited the shell, requiring me to close it manually. I don't know if it's been fixed since.
I remember vanilla vim doing some weird stuff, like leaving the buffer open even though I've exited the shell, requiring me to close it manually. I don't know if it's been fixed since.
- I have a theory that using `coc.nvim` is still the superior solution even compared to a native LSP. Why? Cause we can siphon from the huge man-hours of development and polish that M$ has put on VSCode. Every time they tweak VSCode, we at downstream, enjoy the benefits. Am I wrong in my assessment?
- Vim's regexp-based syntax highlighting is annoying. So I think nvim+tree-sitter is the better solution on this front
I do recommend that new users just use coc.nvim, but not exactly because of what you said.
Both coc.nvim and the built in LSP implementation use basically the same Language Servers, so whatever updates happen to the server will benefit either approach.
However, coc.nvim DOES have a large community that has built a neatly packaged LSP client framework (and many other tie-ins like completion, snippets, formatting, and things like auto-pairs) that is a much more cohesive experience. The built in LSP is best at providing a solid baseline client for those language servers if you really want to tweak everything to exactly how you want it.
If you like that approach where you don't want to configure everything yourself, coc.nvim is probably the "superior" approach for you.
If you have ever said the word "bloat" unironically on your computer with 64G of RAM, built in might be for you.
If you have ever said the word "bloat" unironically on your computer with 64G of RAM, built in might be for you.
I really just want one config that works on:
* Yes, my Ryzen 5 with 32G of RAM
* My Pinebook Pro with 4G of RAM (and like 3.7G accessible) (and limited storage as well)
* My jump host / gateway VM with 512MB of RAM (and even more limited storage than the PBP)
So pulling down and running node.js to use coc.nvim has never been something I was interested in. Before nvim-lspconfig I used LanguageClient-neovim (a Rust client).
A lot of LSPs are written for node though, like pyright for example (yes, the best python LSP is written in typescript). It's kind of unavoidable to use node at some point if you're using LSPs in your editor.
> and many other tie-ins like completion, snippets, formatting, and things like auto-pairs
This is usually where I check out when I get the urge to redo my vim setup. The fact that completion, auto pairs, snippets, and something like endwise are all at odds with each other isn't something I want to deal with.
This is fine in the nvim-cmp world, there's a config example in the lspconfig wiki, it's about 5 lines for the integration. The recommended lspconfig configuration (included snippets and autocompletion) has less lines of code than the example in the readme for coc.
> formatting
This is built-in to neovim's LS client (vim.lsp.buf.formatting()), adding an external formatter can be done with formatexpr (built-in)
I’m not sure if CoC.nvim is necessarily superior. CoC.nvim, VSCode, and all the other nvim lsp plugins use the same LSP servers. The clients are all different obviously, and I don’t think there’s any major features in CoC.nvim that aren’t in neovim’s built in LSP. I’d be curious if someone has a more comprehensive answer for this. I use the built in LSP and have been perfectly happy.
> Cause we can siphon from the huge man-hours of development and polish that M$ has put on VSCode.
Anything done on the language server side is already coc/built-in client agnostic (since communication is done over json-rpc, except for tsserver which MS has not yet exposed via the LSP, so we rely on the typescript-language-server-wrapper), anything on the client side is marginally useful at best.
Theoretically, we could build a plugin that does all automatic setup like COC, but then uses the built-in LSP to do the actual work. nvim-lspconfig already does part of this job - configuring the LSP, as long as the server is already installed. Personally, I prefer the system package manager taking care of the servers, rather than yet another package maintenance system.
Lspconfig currently has 3 parts, the default settings for the servers, an implicit project detector to trigger when to launch the servers (conditioned on filetypes and some patterns), and the infrastructure to manage launching/shutting down/attaching buffers to servers as you open files within the same project.
Eventually we'd like parts 2 & 3 to be in core as a "projects" module, leaving separate "project patterns" and "server settings" as mostly metadata containing repositories.
That would open the door for third party plugins to create customized project templates which map keybindings, set formatexpr, pass custom server settings, etc. similar to how coc.nvim has coc-pyright, coc-gopls, etc. These plugins could also handle installing language servers automatically should they choose to offer that.
There's also nvim-lsp-installer, but I really don't like the approach it takes of hijacking lspconfig's setup.
I came from coc.nvim and switched to the native LSP when it was released on nightly. For a while I was using VSCode and came back to nvim and switched back to coc.nvim.
I found that the native LSP's community to be too quickly changing. Plugins that were necessary earlier weren't, while new necessary plugins came into play. But, coc.nvim was steady chugging along and my old settings file worked out of the box.
I'm also not a huge fan of just the sheer amount of plugins that use the LSP. It seems like every plugin has go-to functionality.
Yeah autocompletions are a mess with native LSP. In the last 6 months or so there have been ~3 different plugins around to support autocompletion, and each one fell into unmaintained or unused status. I hope eventually there is a stable, native solution for it.
Source? We have an extremely extensive test suite for the built-in client that must pass for every merge, and we currently have ~30 open issues on the issue tracker (with a good chunk of those being feature requests).
Yeah I can second this. I've been using native LSP since 0.5 nightly and it's been nothing but solid. The only thing that occasionally gave me issues were tree-sitter crashes (unrelated to LSP), but even those seem to have all been fixed by now.
I agree with your coc.nvim assessment. It’s more cohesive and works pretty much out of the box.
You have to assemble more plugins to recreate the functionality coc provides as a whole and the documentation on the config process is sparse (as of my last attempt to use it). I’m also probably a weird edge case in that my primary use case is writing Powershell. Coc just works and getting native LSP configured and working requires more time than I’ve been willing to give it.
If you're having a powershell issue, you can file an issue. I'm not a Windows user or powershell user, but when I tested the PR (before merging it) I was able to get it running in a minute.
lua is such a nice and sane language for application config. I really enjoy neovim's choice to use it, and with this release more or less allow 100% of typical configuration to be done entirely in lua. Good riddance to bespoke scripting languages.
It's also so much easier to write plugins in Lua than the insanity that is Vimscript. It's why I'm slowly moving into Lua-ifying my configuration away from old standbys like NERDTree to things like nvim-tree.lua.
I really wanted to love nvim, because I think that some philosophies it tries to follow better match my way of thinking. However, I tried several times to configure it to match 1:1 my vim config and to stick to it, but there are several edge cases that vim solves better. Additionally, nvim with my workflow crashes sometimes, while vim doesn't.
As someone who just started using nvim, and assumed that vim was identical (or close enough to it that it can just be considered identical), what are these edge cases/differences?
There are issues in how the terminal is handled and the numbering of the buffers. Moving between the buffers (e.g. C-w, C-t) is not configured by default on nvim.
Does any one have any advice for running neo vim on a centos host without admin to install it. (Short of hunting down all the source packages for dependencies and compiling)
You can download the appimage from the website or you can install it using flatpak. Then set up an alias for "neovim" pointing either to the appimage or to the flatpak command.
and untar into a local ~<user>/usr/local directory that I maintain myself.
Compiling is neovim at work is a hassle, since its dependencies are from sites which are behind a firewall. So I decided to use locally built dependencies. The most painful part was getting the 3 luarocks 5.1 (which is not the latest) packages to compile locally and work with neovim.
The nvim on my work laptop is old being from Ubuntu 21.10 so I went with Nix (because I dont like Snap). Fairly easy to set up, Nix is even included in Ubuntu repo.
You only have to install it once, and update things like update-alterrnatives or play with $PATH.
Neovim is such a weird derivative utility to me. Derivative/forked software usually isn't very successful to begin with, but then Neovim makes attempts to be modern and it's so not appealing at all. Here are some 5 second examples.
Example 1:
nvim .
Still uses Netrw, which is fine, but doesn't even attempt to do things like:
let g:netrw_preview=1
let g:netrw_banner=0
let g:netrw_browse_split=4
let g:netrw_liststyle= 3
let g:netrw_altv=1
let g:netrw_winsize=8
So that you get something that remotely resembles a modern text editor's tree view.
Example 2:
set number
Line numbers are off by default. Why? Why are all of these other configurations on by default? Every editor shows line numbers by default and Neovim doesn't make this 1 line configuration effort to look like everyone else.
Example 3:
set mouse
Mouse is off by default. Again, why? I get that it's a terminal editor, but if the technology is there to allow me to select text with my mouse, why do we need act like luddites?
After setting up my .vimrc file with sane defaults and a bit of an attempt to use the editor in earnest, my conclusion is that Vim/Neovim is just a bad editor.
I want more from my editors.
Here's a .vimrc file that attempts to make Vim and compatible editors more like Visual Studio Code, Atom, and Sublime Text:
You might reconsider your expectations. Neovim is not trying to occupy the same space as something like VSCode or Atom. Its focus is on being extremely extensible without sacrificing performance - just look at the website, it's right at the top of the feature list.
The intention is for it to serve as the core technology for any number of vi-like text editing setups. It's not batteries-included, but there are batteries everywhere if you look.
Mouse is off by default. Again, why? I get that it's a terminal editor, but if the technology is there to allow me to select text with my mouse, why do we need act like luddites?
Because it would be unexpected and unwelcome behavior for most users, and maybe even introduce undefined behavior in clients that lack mouse support.
After setting up my .vimrc file with sane defaults and a bit of an attempt to use the editor in earnest, my conclusion is that Vim/Neovim is just a bad editor.
You haven't really explained why you think it's a bad editor, beyond the default settings you don't like.
I don't want line numbers, IMHO it's an anti-pattern to have them. I'm not writing code trying to maximize the number of lines, or show my boss "look I wrote 10k lines today, so productive!". I'm trying to write less lines of code--if a function is sprawling past a page then I'm getting suspicious that it's too complex.
If I have to remember "ok line 7000 is where the weird permission business logic starts" that's a failure to comment and make clear how the code is structured.
If tooling is telling me there's a problem on a specific line then I should have a code action or command to take me directly to that line, I shouldn't have to juggle navigation manually.
I'm confused on the arguments presented. Is it that the out-of-box functionality isn't as good as other GUI based editors, or that certain things are off by default?
I agree that certain settings shipped with neovim could be expanded. There should really be a process to elect plugins and settings that are generally accepted as "good" for neovim.
Plugins like Gruvbox, vim-surround, coc.nvim, vim-plug, nerdtree etc. have been continuously maintained for years, why not make it easy for new users to install and use them without having to go on the path of wonder?
Will the new remote features allow sharing the same set of open buffers between multiple neovim windows in something like a tmux session? I don't want to see E325 ever again.
One of the more popular and recent LSP autocompletion plugins is written in python: https://github.com/ms-jpq/coq_nvim It appears to work pretty well for them.
It is literally a fork of the vim codebase, and the name clearly indicates that it has diverged. If Tesla had started with a complete copy of McLaren designs, then (aside commercial/trademark issues) it'd be 100% reasonable to call it a "Neo McLaren". (Obviously that wouldn't happen because businesses run differently from FOSS, but the principle is sound.)
vim does not break vi concepts the way neovim breaks both vi and vim concepts.
It's not 'vi with lua support' it's a totally different core paradigm like the difference between vscode and vim.
Someone recently wrote a whole screed about this and itemized a bunch of points about why exactly it's backwards to integrate a terminal vs working within any terminal, baking in more limited answers for things that are already answered more flexibly by plugins and external processes, etc. They got a little bit screedy and there were a few nits to pick, but the basic points were all both true anc valid.
It was posted to HN within the last couple days but I can't find it now. If I find it I'll add the link here.
All of which is not to say that neovim is necessarily a bad thing, it's just that it's not a newer or better vim, and the starting point being a fork of vim doesn't mean a thing.
The first Tesla was a fork of a Lotus.
Both Tesla and Lotus are fine cars, but a Tesla is not a newer better Lotus.
If you like the design goals of Lotus, then a Tesla is utter garbage.
And the inverse is exactly the same true. If you like the design goals of a Tesla then a Lotus is utter garbage.
If I were either Lotus or a Lotus user, and even if cars were open source projects without legally enforcable trademarks on their names, I would be highly highly annoyed when someone comes along and takes the current Lotus and replaces the engine and transmission with electric motors and a PC, and slaps a huge ipad on the dash, and then names it "NeoLotus", and then continues to call it NeoLotus even after the original Lotus base isn't even in there any more and it's a totally different thing with a totally different set of priorities, goals, philosophies, and audience.
