Coc.nvim – Intellisense Engine for Vim8 and Neovim
github.com
github.com
As someone who turns off autocomplete and other features when forced to use an IDE, and otherwise works entirely with code in a plain text editor (sometimes Vim, sometimes Notepad --- and sometimes just good old pencil-and-paper), I can tell you that "live feedback" is a distraction. It interrupts the thinking process like a backseat driver.
Sometimes you will also be required to work from a remote server. I'm not talking about to fiddle bits, I'm talking about real development.
There is also a lot of downsides to not working from the terminal. Vim users are consistently better interviewers because they spend more time interacting at the system level. There are a lot of disadvantages to working with an IDE that turns valuable knowledge into a series of black box buttons.
Please find an example here:
On the other hand, Goland (or Go plugin for IntelliJ) handled modules flawlessly the whole time and they handle monorepo full of go modules flawlessly as well.
My solution thus far is to use VS Code for all git functions (yes, I prefer a UI over command line for git), and use Rider for everything else. It suits me well - VS is basically my dream git UI!
Having said that, I still wish JetBrains would fix the car-crash of their got functionality...
no it doesn't? it explicitly asks you whether you'd like to "add" the file.
Not to mention the productivity increase from having a blazing fast editor that just gets out of the way. Even on my beefy laptop, intellij products feel clunky and slow
I'm not sure I would trust jetbrains - it's closed source and I don't know what data they're phoning home, or telemetry. With vim at least I have the possibility to audit. With a closed source product, it's way harder.
Nothing updates unless you do it, but then once the update is done you can optionally go through the commit log of each plugin and even revert back specific commits if you don't like what you see.
To me that's a much better model than "hi, I see you opened your code editor, let me auto-update these 10 plugins for you. Hopefully things work out for you!".
IMO the user (you) should be in total control over when things get updated. This goes for the editor itself and your OS too. Otherwise you have no idea what the state of your system will be the next day.
I’m amazed. I’ve been using Vim for, oh I don’t even want to count how many, years. My .vimrc is constantly improving. To the point where I ask myself how healthy the obsession/addiction is.
I don’t think I’ll ever make up in efficiency for the time I’ve spent tinkering. But it sure is fun. Mostly.
I’m still quite good at stock Vim though. Specially since recent distros have been shipping a much saner default .vimrc
I have to concede that this _was_ my experience until about a year ago. I can recall spending many evenings and even some lunches reading and experimenting with vim configuration improvements. I too wondered if the time would pay off.
Vim has been my main editor for 8 years. About a year ago I started to notice that I was no longer spending much time at all changing my configuration; however, I was aggressively deleting plugins and complex (most-unused) key-bindings.
These were replaced with intrinsic key-bindings that I didn't previously know about they were replaced with more modern and simpler plugins. I suspect this will get even better once adopt Ale and plug.
The smaller config is oddly satisfying. I'm happy that I've stuck with Vim as it continues to provide me with a full-service experience, while getting faster, not slower, yet my config continues to get more minimalist.
I don't think there is anything out there that compares, but it's an investment and YMMV.
I briefly tried out Coc but didn't find it to deliver anything compelling to make me switch away from a relatively fine-tuned deoplete-powered set-up (along with UltiSnips, LanguageClient-neovim, and javascript-typescript-stdio etc). I like the fact that there is competition though and an LSP ecosystem that's getting more and more robust all the time. We finally have multiple high-quality options to bring IDE-like features to Vim.
I used to use deoplete.nvim, LanguageClient-neovim with javascript-typescript-stdio, but they easily broken lots of time everyday and debug the problems is also quite challenging. So I made it to be able to load fork of vscode extension, and coc-tsserver implemented more than 95% features that vscode could provide. It's not easier to switch vim plugins, consider come back when you would like to try out some new features.
I'll try Coc; hopefully it's fast enough. IntelliSense works great in VS.
It's a sign of massive success, too. Like "Hoover" now being a synonym for vacuum cleaner.
Want to dev in Rust? Get IntelliJ Community Edition (free) with the Rust plugin. I'm sure VSCode can do this too (personally I prefer Jetbrains products and have been using them for 15+ years).
You can of course use a tty-based text editor over an ssh connection and I use that for Linux servers I connect to of course. I just don't write code that way and don't know why someone would.
I'm also wondering when the last time you've used Vim was, because async plugin execution is now a thing, but I switched to NeoVim a while back it's fast.
My vimrc is at: https://github.com/nickjj/dotfiles/blob/master/.vimrc
At work, on OSX, VSCode has been fine though. Still, I've never run into a situation where nvim is slower. And I use a good many plugins (deoplete, ALE, ctrlp, fzf, and 5 sets of language specific plugins).
I tried looking into Vim / NeoVim a few times to understand what all the hype was about.
I had to install:
* Fugitive * Nerd tree * Airline * YouCompleteMe * Emmet
And I don't remember how many other plugins just to get a halfway decent editor experience. I get using Vim if you're SSHed to a server, but otherwise it feels like intentionally handicapping yourself. In case you find yourself needing keyboard based navigation, I'm pretty sure Command+P is much better than anything Vim could offer for quickly opening files, and there's a Vim plugin for VSCode for moving around in files.
I will probably get heavily downvoted for saying this, I know. But if someone feels like enlightening me instead, please do so.
If you're used to IDE's it's doubtful you'll appreciate vim by "trying it out" for a weekend. The learning curve is much too steep for that. Conversely, if you've used vim and terminal tools on a daily basis for >15 years, you probably won't have much motivation to switch to GUI-based IDEs.
Is vim really getting hyped anywhere? If so that must be one of the longest running hype trains in tech.
* A new language or paradigm comes out
* Clicky tool makers (IDE, management software, etc) can't really keep up with the rapid change, and they aren't sure if this will catch on, so they don't make great tools for it. People have to use the cli tools to take advantage of all the features.
* Since folks are already in the shell, they want to make their environment better, so new folks are introduced to shell stack, and new customization options for tmux or shell or vim come out.
* Eventually if the thing catches on Clicky tool makers catch up and the shell scene quiets down a bit - people abandon shell stack for clicky tools if that's their preference, and the new shell converts integrate with the broader "shell folks community". (That community is always there, just quietly using the relatively stable interfaces in the background).
* At some point a new language or paradigm comes out...
That being said I have spent tens of hours trying to get everything just right in Spacemacs.. and some things dont work still.
if this is possible... please teach me! i searched online and only found articles about enabling basic vim keybindings and gave up after that tbh.
But yeah, airline is mostly just eyecandy.
Actually, you're wrong here: https://github.com/kien/ctrlp.vim.
https://github.com/junegunn/fzf.vim
Fzf is an incredible fuzzy finder, integrates into your shell really well (history search is brilliant) and the wrapper in vim is lightning fast.
Ctrl+P inside of VSCode is way way way slower than fzf with Vim. Even Ctrl+P with VSCode on a small amount of files had some amount of lag on it but fzf and Vim is nearly instant with thousands of files. There's also a lot of great fzf related shortcuts with Vim too, like being able to search more than 1 file with ripgrep or searching through lines in a file, etc.. All of which are super fast operations. I can search through a 900,000+ word markdown file (over 100,000+ lines) in Vim instantly with fzf's line searching tool.
I've been using (Neo)Vim for a couple years now and only regularly use 6 plugins that actually do something, and 2 additional ones for the eyecandy. All the rest is just a matter of knowing the features that already come in Vim, and efficient keybindings for them.
Also, Vim isn't something where you can just jump in for a test drive. You never stop learning Vim and it takes time. But once you get hooked you won't use any other editor without a Vim plugin, no matter where you end up eventually.
In those 3 years I spent 3-5 hours in total configuring my .vimrc to make it work exactly as I want.
I can compare directly my productivity using Vim and other IDEs and I'm like 50% more productive using Vim.
Want to customize your build? Just drop into shell and edit your scripts. Im sure $IDE can do this too (personally I prefer just fixing the relevant script, since finding obscure features 15 layers deep in some random menu got old 15+ years ago).
You can of course run some scripts via menu when you're in IDE, and I do it when I'm IDEing of course. I just don't limit my flexibility that way, and don't know why someone would.
how often do you need that though ? for me it's less than 5% of my projects which need "special handling".
I do a lot of systems stuff that can affect fs/network/etc so i have lots of scripts when developing to get everything set up pristine (I guess I use the term script to also mean Dockerfiles or helper utilities too - basically something that execs a command provided by the OS :) ). Those are modified a lot as I add features or integrations, or fix bugs, or whatnot.
I knew a guy with a heavily customized vim setup for development. He could write code without it because he was so used to his custom config. How is that any different?
I have seen many people who have absolutely no idea how the Java compilation process works because they've never had to do it from the command line, but have interacted with it mostly through IDE tools that have abstracted almost everything away.
And when something actually breaks or is idiosyncratic enough for the IDE to not handle it, they end up very lost.
I thought the point of a menu was you didn't have to learn much at all.
And the worst part is you can't even run a text search on those menus!
sigh
https://blog.jetbrains.com/idea/2009/06/find-action-saves-ti...
That feature doesn't make menus better. It makes the IDE better, by giving you a way to avoid the menus, because [sigh] menus suck.
I find it more time consuming to go through a bunch of menus and GUI windows to find something I'm trying to do vs being able to just run a command or Google for a command and run that instead.
Plus, for common actions with annoying to type syntax you can make a custom key bind (Vim) or alias (Bash). Then it becomes extremely easy to do once you memorize a single key bind.
Have you ever even used a modern IDE?
I don't think I've actually clicked on a menu item in IntelliJ like, ever. Not once.
I just press "shift shift" and get the the "search everywhere" dialog which searches everything including menus and customization preferences.
Yes, I used PyCharm and RubyMine for over a year. The comment I was replying to said he was clicking around menu items to see what's available.
I don't really see a difference between using "search everywhere" vs using something like fzf with Vim (which lets you search through a ton of different things besides files).
But normally in my day to day I'm just hitting key binds or typing short commands without having to search for anything except files to open (which I could do with a sidebar instead, but I prefer fuzzy finding files based on typing out the name most of the time).
Vim's help command is also world class. It's just searching it is hard, but fzf.vim makes this easy, so you can literally type 1 word of what you want to learn more about and you'll find all sorts of results.
What I do get is correct autocomplete, documentation hinting, inline git hunk visualization, inline linter and compiler output, go-to-definition that always works and sees through implicitly satisfied interfaces, language aware refactoring tools, well designed interactive debugger, etc.
Sure you can hand assemble this stuff in Vimrc, or you can buy a tool that’s already functional.
Just one feature alone - being taken directly to compiler error sites - has saved me so much stumbling around from back when I was trying to be a shell purist.
As I’ve gotten more senior, I’ve really come around to the importance of investing in tooling (whether build or buy), having high expectations for tooling support, and having low tolerance for frustration/tedium/trickery. Not just IDEs. The right interactive debugger output, profiler trace, custom visualization, etc. easily pays for itself vs. trial and error or trying to squint at the source + output and reason about it.
You're in luck - this killer feature doesn't even need a plugin in vim. Just type `:make` and you'll get taken to the first build error.
From time to time I try to switch to IDE or another editor, but I easily get lost. I work on a big screen so I want to split my window into 2/3/4 parts to see multiple files next to each other. Vim has built in shortcuts for that and in my vimrc I added 2 lines to make custom shortcuts that are even simpler. How do I do it in Intellij? The most common way is to use mouse, which I find annoying since with Vim I'm able to use keyboard 100% of the time. There's also a way to add shortcut for that, but it's buried deep into settings (Settings -> Keymap -> Main menu -> Winddow -> Editor Tabs -> Split vertically / Split horizontally).
I guess what I'm trying to say is that what you consider "poor version of (...) functionality that comes out of the box with the most basic of IDEs" is enouh for me, and I've been coding in multiple languages over the last few years. On the other hand in other editors I have to slow down my development due to lack of good editing shortcuts or I have to invest significant amount of time into making sure that I can recreate these or similar shortcuts.
You are then left with choosing between the comfort of using the subset of vim that isn't available through the plugin, and the comfort of using all the IDE features that aren't available in vim. I believe that for most people the latter will be far more productive.
The IDE's config might be synced. If it is it probably uses a proprietary server.
I use VS Code sometimes, and got it configured to run unit tests on live code and constantly report on passing, and then I went back to vim. I don't need a herd of assistants begging for my attention, and it hurts my productivity.
I think that it's the other way around: people don't want to lose the editing experience that they already have by switching to another environment that might have some other benefits. For some people, that means an environment that they've tuned to their own requirements over years, and for others, it's just the core interaction model.
For me, I like modal editing, and the Vim commands are now automatic, but I have no attachment to any implementation of these, so I use the stock Vim on CLI, and VS Code with the Vim extension everywhere else to get modern features without losing the aspects of Vim that I really care about.
The uninitiated always stumble around with vim like bumbling bafoons wondering why anyone would use something so antiquated, but in the right hands vim becomes an elegant weapon for coding at the speed of thought.
A pity that for want of a GUI, most will never feel the power.
I'm not sure how this criticism applies to the post; it's a single plugin that adds language-server capabilities that almost every IDE is using today.
> Want to dev in Rust? Get IntelliJ Community Edition (free) with the Rust plugin.
Alternatively, if you use vim, you can just as easily download the popular rust.vim plugin which was written specifically for vim by the rust development team.
poor versions of that comes out of the box with the most basic of IDEs.
The functionality isn't "poor" or in "narrow slices"; with few exceptions Vim is fully capable in terms of IDE features and actually exceeds what is possible with most IDEs individually. Products like the IntelliJ suite of editors will always have more "out of the box" features because their business model is selling IDEs with lots of features. IMO the vanilla editor + plugin model is superior because it allows you to select your features a la carte as they make sense for your workflow rather than being thrown into a bundle of different features, many of which you don't need and most of which you'll never use. With Vim, every feature is deliberate and the experience can be super lightweight or relatively heavy, but ultimately customizable to the point of perfection. Of course, tweaking Vim to be your perfect IDE takes time, but that's the tradeoff for a self-tailored experience vs one that was designed for you based on someone else's ideal workflow. There's nothing wrong with just picking something off the shelf and learning it, but some people want to optimize their workflow and most people end up switching IDEs over time anyway, so I think the idea that you can simply learn one thing and use it forever isn't typical.
> I just don't write code that way and don't know why someone would.
I prefer it because its fast, clean, open source all-the-way-down, and I can manage and access my entire development environment remotely from any machine, with full fidelity and capabilities. Tty applications also combine beautifully with tmux allowing me to arrange my editor into tight visual coordination with other commonly related tasks that are specific to the context of the files i'm editing (e.g. tailing logs, running binaries/scripts, copying/moving files). Additionally, tty applications tend to integrate very well with eachother since the designers tend to have an appreciation for the the unix philosophy.
Is it really "just as easy"? The last time I tried to install plugins for Vim it was not easy. Vim doesn't have a plug-in manager built in while VS Code, in this case, does, and it's 2 clicks to install and restart.
I would consider vim more customizable but I would not consider it "easier".
I believe it's easier to start with one of existing Vim configurations like Janus[0] or spf13-vim[1]. I tried a couple of such frameworks and they helped me a lot. They come with set of packages for navigation, fuzzy finding, as well as with some package manager. They're also quite easy to install.
[0] - https://github.com/carlhuda/janus/ [1] - https://github.com/spf13/spf13-vim
Easy to add new plugins, update and so on. And it’s usually just download one file to make it work.
It's dead simple. No, it doesn't come out of the box, but it takes literally 5 minutes to install a plugin manager and you only have to do it once; afterwards, installing, updating or removing plugins takes literally seconds.
I work mostly in ruby and the vim ruby experience is great. I have spent a year watching coworkers work in RubyMine and there isn't much it provides that I can't do (literally) just as well in vim. In fact the navigation tools are superior in vim as far as I'm concerned. RubyMine does have better project wide refactoring support, but with ruby being a dynamic language, you still have to go and check every file that changed to make sure it did the right thing anyway.
It's a good thing somebody put the effort into the Rust plugin for IntelliJ CE. When I started writing Rust, I used vim with syntax highlighting, so I guess I might be part of the reason Rust became popular enough to get IDE plugins. You're welcome.
I mean what is the point of this comment if you don't know? What comparative warrant is there to even discuss? Having attempted to move to Sublime, Atom, VS Code with their respective Vim extensions is _not_ the same thing if you understand how to vim, so mucking around in your respective $GUI_EDITOR's Vim mode is never going to be a symmetrical experience, not even in a "good enough" way cause you always end butting up against the inherent design of the $GUI_EDITOR. It's true that vimscript, package management, etc could stand to be given a second look, but those things aren't showstoppers and have no bearing on the central value proposition.
I strongly suggest all developers disable completion & tag jumping, not because I’m an elitist, but because it forces you to write better code. Not a troll. I’m serious.
On projects I’ve worked on that started with Intellisense, they quickly evolved into being unmaintainable without it. It’s an asset to skilled hands, but a debilitating crutch for the novice.
It’s like never operating a vehicle without a GPS. You never develop certain types of skills.
A few years ago, I started working on a project where I needed to use C#. I'd never written a line of C# in my life, so I installed VS and with the aide of Intellisense, I went from having a "Hello World" snippet from Google to using several C# libraries to create a ~1000 line PoC in a day. A few days later, it was production ready. Without Intellisense, this story would be very different.
Maybe it's a question of mindset & philosophy. I personally prefer a minimalist but powerful editor without plugins and just rely on their internal capabilities (which granted are a learning curve). It avoids getting stuck when doing $EDITOR foo on a system you don't own and still feel at home and as fast as on your primary workspace.
"How to Do 90% of What Plugins Do (With Just Vim)": https://www.youtube.com/watch?v=XA2WjJbmmoM
This makes me believe that either I have a really poor memory by not being able to memorize thousands of method names, their parameters and orders or other devs have a really, really good memory.
You now have to leave your context and “break the zone” you’re in to find the symbol name you want you use elsewhere, you’re at the very least less productive as a result.
I’d also expect code quality to suffer, given the number of issues I’ve found thanks to code analysis, type checking, linting and spelling that we’re able to highlight, catch and resolve human errors before shipping.
Usually I kind of know what I want to do with an object so I start typing ‘myObject.’ and the editor shows me all possible methods with their argument types. It’s way faster than looking up the docs. And in the case of Java/Kotlin in intellij you get the documentation right along the method names and types.
Edit: replaces ableist phrasing with more precise term.
https://www.emacswiki.org/emacs/HippieExpand
I’ve long since changed my mind and really hate not having great auto-completion.
I find that grabbing pen and paper and looking at the problem from a high-level avoids the problem where you code-monkey the program by just quickly banging away at the keyboard.
I'm not relying the autocomplete functionality per se, but they make discovering these kind of code easier.
It limits the scope & necessity of domain knowledge to be scattered about everywhere. The core logic is easy to reason about and there’s no tight coupling.
For example, if I’m calling libcurl directly in C++, I’ll create a generic adapter. Auto completion isn’t adequate for that library anyway, unless you can remember the docs.
If it’s some unwieldy “does everything” internally developed monolith by a team from hell, the same applies. Encapsulated composition.
Scott Hanselman has a great tweet chain (or blog article, can't remember) on the fact that you have a limited amount of keystrokes in your life. I'd rather not waste them on something a machine could do.
It is a powerful tool and you should be aware of that power and act accordingly (meaning: know exactly what you are typing and don't fall for bad suggestions).
It also helps you to make better code by showing diagnostics.
Modern pandas is supposed to be written along the lines of
import pandas as pd
df = pd.read_csv().transform().agg().pipe() #etc, etc
I tried YouCompleteMe but on a 500k line codebase, as well as it works, it's just too slow to stay below the constant annoyance threshold. Would like to play around with adding C support and see how this performs
https://github.com/neoclide/coc.nvim/wiki/Language-servers#c...
I personally installed ccls and it works as expected.
Don't forget to install yarn, not super happy about that.
1. Check out the built in completion first. Vim actually has very powerful autocomplete that can look in the current file, complete file paths, tags, and more. It can look at includes, requires, etc. depending on your language's built in support. For C like languages this is usually excellent. With ctags and this built in completion, you can get 90% of what an LSP will give you.
2. Chances are you've already installed ALE, it's a pretty standard plugin. ALE has built in LSP support, and it's entirely written in vimscript. All you have to do is create an ftplugin for your LSP language and add the LSP into the configured linters list. This is in the primary docs.
The big advantage of coc.nvim is it can load extensions forked from VSCode, which have more features most of the time.
You can use both of them as the same time, and coc support send diagnostics to ALE.
Out of curiosity I checked out if Vundle would give me YouCompleteMe but... vundle installation of YouCompleteMe just failed with `The ycmd server SHUT DOWN (restart with ':YcmRestartServer').YCM core library not detected; you need to compile YCM before using it. Follow the instructions in the documentation.`.
I love Vim but I have stopped trying to build a cathedral for it.
Maybe we'll soon run vim in docker.
There you go. Dein is integrated and has GUI.
I know, you can set this up yourself e.g. through git, but this is an extra step to take whenever you have to configure a new machine.
For a more complete vim experience out of the box, check out spacevim.
https://raw.githubusercontent.com/vim/vim/master/runtime/doc...
Master your debugger. GDB? learn to use it.
You are set for life and can work on any language, anywhere, any time. Everyone wants a ready-made IDE, and it's great when it works out that way for your current dev environment. But it won't work for all languages, or for all project set ups.
Unlike GDB, right?